Cloud Developer - docker #1に参加しました。
cloud.connpass.com
ExmentとDockerとAzureとOffice365
www.slideshare.net
途中から参加したため、残念ながら聞けませんでした。
DockerとChefとAnsible
DevOpsはパラダイムシフト
- Dockerは1つの解
- ミスではなく、バグが残る
- 人間が介在しない
- 再現性がある
- 可視性
- 頑健性
- 生産性の向上と品質の向上はトレードオフではない
- 手順をプログラムで書く
仮想環境
SSD
手順書をプログラム化すると
- 直接運用環境を構築可能な状況になる
- ミスコミュニケーションがなくなる
- 運用の人が手順書実行ロボットからインフラエンジニアになる
旧来型SIerの単純な人月ビジネスモデルの終焉
運用にAgileを
DevOpsの課題
- CPU/メモリ/Diskフットプリントがバカにならない
- ノードの数が増えるとやっぱり管理が大変
- フレームワークを覚える必要がある
コンテナ
- Kernelは共通
- プログラム同士がお互いに環境に書き込めないように制限する
- ハードウェアをエミュレートしているので性能は低下する
コンテナの長所と短所
- 長所
- プロセスなのでOSよりは起動が早い
- kernelは1つなので、フットプリントが小さい
- ユーザーデータの保管場所の分離
- 短所
- kernelは共有なので、セキュリティは低下する
- ユーザーデータの保管場所は別途検討
エンタープライズの未来
- DevOpsを中心にしている会社と、そうでない会社の生産性の差が拡大
- 仮想化は、コンテナとともに、コンテナは、DevOpsとともに。
- さらにその先へ
AWSでのDocker(良かったところ/悪かったところ)
この4つだけは頭に入れる
良かったところ
- デプロイ更新が早い
- ミドルウェアや環境変数を変えるのが楽
- 開発環境はDockerにして本当によかった
大変だったところ
- コード化したけど、それも複雑
- ダメなコンテナが自死する。ALBヘルスチェックに殺される
- 高負荷により死。またはECSの機能不全
- コンピューティングリソースが枯渇して、新しいコンテナをデプロイできない
- CPU使用率が100%になるとECSAPIエンドポイントとの通信に失敗することがある
- エラーが起きたのが、どのインスタンスのどのコンテナかわかりづらい
Docker
- 余力と技術力があるところが手を出すべき
- Dockerでなければ、実現できない/さばけない、DockerでのDevOpsで改善しないと勝負に負けるなんてシステムや要件はほぼないはず
Dockerに触れておくことは無駄ではないと思う理由
- 最近のOSSの動作マニュアルがDockerで動かすことを前提としている
- DockerというよりLinuxのお勉強になる
- シンプル/疎結合さを強制させられる
ロギング戦略
- コンテナの中にログを送信するAgentをインストール
- ログ転送用コンテナ
- ボリュームをマウントさせ、そこにログを書く。ホストOS上のAgentがログを転送
- ログモニタリングツール(kibana)
ロギングツール
- Grafare & Prometeus
- Zipkin
- Jaeger
- EFK Stack
おすすめの教材
k8sについて
実践ガイド著者が語る!Docker EEとDC/OS基盤
欧米企業の戦略:OS+アプリ構築作業を極力やらない
- Dockerイメージ
- 仮想サーバーと違って構築する必要がない。イメージを入手して起動するだけでよい
- 公開されているイメージを自分の業務向けに手を加えてイメージを作成する
- 引っ越しが楽、高い可搬性
- どんな環境でも全く同じ動作をする
- Docker社の発想「紙の手順書」をなくす
- 従来のIT基盤構築
- 優秀な技術者が紙の手順書を忖度してインフラを構築してしまう
- Dockerfile
- 手順のコード化:自動化
DTR(Docker Trusted Registory)を経由したDockerイメージの共有
開発部門がネットから入手したDockerイメージを信頼できるのか?
- IT基盤
- コピー後検査
- 脆弱性チェック
- Docker EEによる脆弱性検査
- Communityエディションのときは人海戦術で全バイナリを検査していた