Cloud Developer - docker #1に参加しました。
ExmentとDockerとAzureとOffice365
www.slideshare.net
途中から参加したため、残念ながら聞けませんでした。
DockerとChefとAnsible
DevOpsはパラダイムシフト
- Dockerは１つの解
- ミスではなく、バグが残る
- 人間が介在しない
- 再現性がある
- 可視性
- 頑健性
- 生産性の向上と品質の向上はトレードオフではない
- 手順をプログラムで書く
仮想環境
- 作ったり壊したりするのに時間がかかるのはつらい
SSD
- HDDではOSの起動に時間がかかるので、非現実的
手順書をプログラム化すると
- 直接運用環境を構築可能な状況になる
- ミスコミュニケーションがなくなる
- 運用の人が手順書実行ロボットからインフラエンジニアになる
旧来型SIerの単純な人月ビジネスモデルの終焉
運用にAgileを
DevOpsの課題
- CPU/メモリ/Diskフットプリントがバカにならない
- ノードの数が増えるとやっぱり管理が大変
- フレームワークを覚える必要がある
コンテナ
- Kernelは共通
- プログラム同士がお互いに環境に書き込めないように制限する
- ハードウェアをエミュレートしているので性能は低下する
- 通信速度
コンテナの長所と短所
- 長所
- プロセスなのでOSよりは起動が早い
- kernelは１つなので、フットプリントが小さい
- ユーザーデータの保管場所の分離
- 短所
- kernelは共有なので、セキュリティは低下する
- ユーザーデータの保管場所は別途検討
エンタープライズの未来
- DevOpsを中心にしている会社と、そうでない会社の生産性の差が拡大
- 仮想化は、コンテナとともに、コンテナは、DevOpsとともに。
- さらにその先へ
AWSでのDocker(良かったところ/悪かったところ)
この４つだけは頭に入れる
- タスク
- ひな形、コンテナの設計書
- サービス
- タスクを動かす。LBと結びつく
- ECSインスタンス
- EC2インスタンス
- クラスタ
- ラベル
良かったところ
- デプロイ更新が早い
- ミドルウェアや環境変数を変えるのが楽
- 開発環境と本番環境で同じイメージを使える
- 開発環境は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
おすすめの教材
- ドットインストールDocker入門
| Docker 実践ガイド (impress top gear) | ||||
|
| Dockerによるアプリケーション開発環境構築ガイド | ||||
|
| Docker/Kubernetes 実践コンテナ開発入門 | ||||
|
k8sについて
- Pod
- コンテナ
- Service
- ロードバランサ
- github.com
実践ガイド著者が語る！Docker EEとDC/OS基盤
| CentOS 7実践ガイド (impress top gear) | ||||
|
| OpenStack 実践ガイド (impress top gear) | ||||
|
| ビッグデータ分析基盤の構築事例集 Hadoopクラスター構築実践ガイド impress top gearシリーズ[Kindle版] | ||||
|
欧米企業の戦略：OS+アプリ構築作業を極力やらない
- Dockerイメージ
- 仮想サーバーと違って構築する必要がない。イメージを入手して起動するだけでよい
- 公開されているイメージを自分の業務向けに手を加えてイメージを作成する
- 引っ越しが楽、高い可搬性
- どんな環境でも全く同じ動作をする
- 開発環境、本番環境
- 大阪DCから東京DCへ
- Docker社の発想「紙の手順書」をなくす
- 従来のIT基盤構築
- 優秀な技術者が紙の手順書を忖度してインフラを構築してしまう
- Dockerfile
- 従来のIT基盤構築
- 手順のコード化：自動化
DTR（Docker Trusted Registory）を経由したDockerイメージの共有
- イメージの脆弱性チェックを実行
開発部門がネットから入手したDockerイメージを信頼できるのか？
- IT基盤
- コピー後検査
- 脆弱性チェック
- Docker EEによる脆弱性検査
- Communityエディションのときは人海戦術で全バイナリを検査していた
- コピー後検査
