DigitalOceanをざっと眺めて気になった点
クラウド事業を展開しているところに従事している都合上、他社サービスがどんな風になっているかきになるお年頃なのです。
先日、DigitalOceanを触り始めたのでそのメモ
コンパネ
- 白を基調に水色で綺麗
- 何が動作するのかは分かりやすい
- ただしわかりづらいところは、本当によく分からない(後述する)
- 料金が明示的ではないので、お金のかかり方がよく分からない
インスタンス
メモ
- 基本10個まで
- 上限解放できそう
- OS
- リージョン
- いろいろあるが日本リージョンは無い
- 地理的な話だと一番近いのがシンガポール？
- オプション
| 価格 | cpu(vCPU) | メモリ(GB) | ディスク(GB) | ネットワーク流量(TB) |
|---|---|---|---|---|
| 5 | 1 | 512MB | 20 | 1000GB |
| 10 | 1 | 1 | 30 | 2 |
| 20 | 2 | 2 | 40 | 3 |
| 40 | 2 | 4 | 60 | 4 |
| 80 | 4 | 8 | 80 | 5 |
| 160 | 8 | 16 | 160 | 6 |
| 320 | 12 | 32 | 320 | 7 |
| 480 | 16 | 48 | 480 | 8 |
| 640 | 20 | 64 | 640 | 9 |
雑感
インスタンスの設定とローカルディスクのサイズが関連してしまっているので, 中サイズのインスタンスを後に, 小さいインスタンスにすることができなさそう.
なので「インスタンスのサイズを下げてコストを抑える」とかのクラウド的な基本テクが使いづらい.
日本リージョンが無いのは割と残念.
$10でまともなVMが借りることができるのは本当にすごい.
ネットワーキング
雑感
- LBが安いと思う
触っていないもの
- volume
- API
- Image
最後に
あなたがdocker-ceをcentos7にansibleでインストールしたい時に読むべき記事
タイトルの通り。
あと2017/03/03に書かれている記事なので注意
dockerがリリースサイクルを変えて、多分リポジトリの情報の配布方法も変更した模様。
具体的に言うと、 yum-config-manager ってやつを使うようになった。
ansibleでyum-config-managerコマンドを扱ってくれるモジュールは現状なさそう。
yum_repositoryモジュールはrpmで配布するやつを扱うので今回のケースではうまくいかない？っぽいのでワークアラウンドを書く。
ワークアラウンドだと思うし、本当にyum-config-managerを扱うモジュールがいないのか？は疑問なところだが、それは後日もう少し調べる。
以下はplaybook
- name: install yum-utils
yum: name=yum-utils state=present
- name: add docker repo
shell: "yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo"
args:
chdir: "/etc/yum.repos.d"
creates: docker-ce.repo
- name: install docker-ce
yum: name=docker-ce state=present
- name: restart docker
systemd:
name: docker.service
state: restarted
daemon_reload: yes
enabled: yes
shell moduleでなんとかする方向でやってあげると良さそう?
ちなみに、この記事を書いてる時点でインストールされるdockerのバージョンは以下
# docker --version Docker version 17.03.0-ce, build 3a232c8
Emacsでドキュメントを読む
2017年、何としてもemacsを捨てたい気持ちと、emacsの使い方を学んでしまいより快適な環境が手に入ることによる喜びで葛藤が生まれています。
そんなことはさて置き、emacsで諸々のドキュメントを読む方法を軽く纏めます。
man
標準パッケージの woman を使えば良い
M-x woman の後に適当に知りたいコマンドを叩く
python
helmを使う前提になってしまうが、以下を参考に、helm-pydoc.elを使う
golang
go-modeから引ける
M-x godoc の後に、適当にパッケージ名を入れる
ansible
以下を使う
yaml-modeと連携するので、yaml-modeを先にインストールしておくのがベター
以下は軽く調べて無かったもの
- Dockerfileのためのドキュメントを見る.el
- docker-compose.ymlのためのドキュメントを見る.el
2015年以降に増えたgTLDにご注意を
仕事でネームサーバーを扱うことになるかもしれなくて、DNSとはどのような働きをするかを調べてるうちに、
ふと思い立って、 .cloud ドメインがあるかないかを調べてみた。
結果としてはあったのだが、それはさて置き、それ以外も調べた結果、現在所属している会社的に取られたらまずそうなドメインを2こほど抑える結果となった。
調べた過程で分かったこととして、 fujitsu.cloud や ntt.cloud あたりは全然関係のない外国の方が抑えている
なにやら2015年あたりに増えたgTLDあたりが割とノーマークになっている様子
現在のTLDのリストは以下で観れる
厄介なのは、 .コム (xn--tckwe) などの文字列に対してaliasが貼ってあるドメイン。政府などがあるが、読みを見るに中国のドメインっぽい。「グーグル」なんてドメインもあるらしい。
真面目に調べたら、これ抑えられていなくて良いのか？というやつが山ほどある気がするので、転売目的の方などに取られて不要なお金を支払う羽目になる前に各自ご注意を.
メンテナンス用データを生成するツールについて僕の思う事
結論
bin/rake db:migrate
が 機械的に 実行されるような環境が最強だって事に気がついた.
不要な中間形式もなく、誤ったデータを使う可能性もかなり減らせる.
良いと思う所
手動で bin/rake db:migrte すると考慮すべきパターンが増えるため, 機械的に が超重要. 考慮すべき間違いが減る. おそらくは, 間違ったデータを挿入しないか否かだけを考慮すべき状態になる.
また上記のコマンドは暗黙的に、gitできちんとワークフローを回していれば、productionやstagingに取り入れられて問題ないとされるデータしか入ってこないはずなのも良い点である.
但し書き
bin/rake db:migrate
でokなのは、ActiveRecordを使ったプログラミングがみんな出来る前提なので、そこら辺だけ要考慮
BSD系のコマンドを読む下準備
TypeScriptのブログを書くと言っていたけど, そんな暇もなさそう.
業務で色々なプロトコルに触れて(OSIで言うところのデータリンク層~アプリケーション層まで), わからないことだらけで困っているのが現状です.ただ分からないと嘆くだけでは前進できないので, せめてwebシステム開発の出身なんだから, HTTPサーバーを切り口に色々と勉強しよう！と思ったわけです.web上の人達もサラッとhttpサーバー書きました！みたいなノリなので.
まぁ結果としては、C言語を殆ど触ってこなかった自分としてはムズい.
もう少しレベルを下げて, まずC言語を取得しよう!というところに焦点を当てて勉強をしようと思った際に見つけた記事が以下
lsコマンドをハックしてみよう - Yahoo! JAPAN Tech Blog
なるほど. 過去の(現在でも?)yahooでは新人にBSD系のコマンドを読んで学習することを推奨しているのか.ならば自分も取り組めるのではないか？というところで, 本日はその下準備.
必要なもの
- FreeBSD
- VMを立てられる環境
- The FreeBSD Project から入手できるiso
前提
普段は CentOS + zsh + tmux + emacs で作業をしているので, それっぽい環境に近づけたい
準備
- VMに対してisoでFreeBSDをインストール
- tuiに乗せられて適当にエンターを押していけば問題なし
- その過程で適当にユーザーを作る
- 作ったユーザーを
wheelグループに属させる pkg install sudovisudoでwheelユーザーにsudoする権限を与える
- 適当に作ったユーザーでsshし、
zshtmuxemacsgitあたりをインストール - GitHub - freebsd/freebsd: FreeBSD src tree (read-only mirror) から
git cloneしてくる
詰まったこと
Angular2のチュートリアルに取り組んだ感想
上記のページの配下の
Tutorial: Tour of Heroes - ts - TUTORIAL
に取り組んだ後の感想を書く.
背景
12月の配属発表で, 今後はJSを書くことはほぼ無い事が確定したと思っている.
であるならば, 正月くらいは今後触らないであろう技術に積極的に触っていくのが吉では無いかと考えた.
去年はES6とReactでSPAもどきを作るくらいは頑張ってみたが, その組み合わせ自体は良いと思いつつ, ビルドの環境を作るのが面倒だし, ボイラープレートを適当に拾うのも面倒だし, ReactとES6以外のライブラリどうするか問題があるし.
本職としてJSを書き続けるならまだしも, 片手間でJSを書くのに色々と選ぶのは面倒くさい.
そんななかで, Angular2はTypeScriptを採用して, フルスタックにライブラリ(RouterやHTTPクライアント)を持っていることをふと思い出した.
JSに関する事前知識
- Angular
- Backbone
- CoffeeScript
上記はいずれもプロダクションのコードを書いた経験あり
ES6は体験済み
- Reactも体験済み
ただし両者ともプロダクションでの経験ではない
TypeScript未経験
- RxJSも未経験
取り組んだこと
2016/12/31 ~ 2017/1/2 にかけて開いてる時間をちょこちょこ使い,
Tutorial: Tour of Heroes - ts - TUTORIAL
上記の英語のうち, Angularに関する解説はほとんどすっ飛ばし, 何がやりたいのか？だけを拾って, ひたすらサンプルコードを書き写す作業に取り組んで, TypeScriptとAngular2の雰囲気をつかんだ.
感想
ほとんどの解説を飛ばしたので, よくわかってないところ, 認識が間違っている事はたくさんある前提で
環境
上記のリポジトリを引っ張ってきて, npm install && npm start で即始められる体験は最高に良かった.
が, 上記のボイラープレートは, ファイルの変更とブラウザとを同期するタイプなので, 最初のうちは, TSのコンパイルが失敗してたのを見落とすと??? という感じの状況が長く続いた.
またこのボイラープレートは, コンパイル対象の ts ファイルと同じディレクトリに js.map と js ファイルを吐く. 要は 'js' と 'js.map' と 'ts' が混在することになる
色々考えると ts と js は別ディレクトリに吐かれて欲しいので, プロダクション環境で使うときに要検討の箇所になると思う.
すこし調べた感じだと、TypeScriptのコンパイラの設定でどうにかなりそう.
Angular2に関して
チュートリアル程度ならば、
ビルドの環境を作るのが面倒だし, ボイラープレートを適当に拾うのも面倒だし, ReactとES6以外のライブラリどうするか問題があるし
上記の問題はほぼ解消
サーバーサイドのプログラミングを書いているときと、似ているような考え方で写経できたという感想.
- module
- service
- component
- html
- css
- 通常のClass
Angularのコードは上記したように分類が出来るっぽい. MVCモデルとマッピングするとしたら, componentがContoller, serviceがModel, htmlがviewになるのかな? componentの中で, templateのhtmlとそれに対するcssをパスで設定出来るのは結構良いのではないか? と思った. ただし, templateはAngular1の頃と同様に、 ngIf みたいな文法が入ってくるのは個人的に好みではない.
jQueryのコードと比較して, Angular2やReactの様に, コードに対してテンプレートが紐付いている状態は色々と考えることが少なくて済むのは非常にデカイ.
DIは良いよね！って感じなんだけど, DIするにはInjectable書けばそれっぽくなるでしょ？くらいの理解しか現状ない. たぶんAngular2のDIを知るとかよめばすんなり理解できそう.
この次に取り組むべきだと感じたこと
以上のような流れになると思うので, TypeScriptの文法とtscを抑えると思う. ので, たぶん次の記事はTypeScriptの話になる.
