コンテナ支部の＃４にいってきた
こんにちは。smallpalaceです。
3末にJAWS-UGのコンテナ支部の#4に行ってきましたので備忘録です。
https://jawsug-container.connpass.com/event/51776/
ハッシュタグ：#jawsug_ct
https://twitter.com/search?f=tweets&vertical=default&q=#jawsug_ct&src=tyah
あとで↓こちらで配信されると言っていました。
---
前佛さん
CLIなどの話
コンテナは技術、Dockerは使用
DockerHubが中継点
コマンドでコンテナとイメージを操作
技術と仕様
技術はコンテナ、仕様は使用
環境が異なる問題を解決
すべての依存関係をパッケージ化してコンテナとして動かす
LinuxKernelのコンテナ技術：
namespaceとcontrol group(cgroup)の制御により、
プロセス環境をisolate（分離）し、リソースも制御できる
この技術をDockerEngineで制御
LXC,libcontainerを使っていた、
いまはdockerd、containerdとrunCを使っている
（ライブラリとデーモンの話
通常LinuxサーバではinitをプロセスID1としてその下にプロセスがツリー上にぶら下がっているが、
それぞれのコンテナ内ではそれぞれPID１になってる
コンテナ内のファイルシステムも同じように/からはじまっているがホスト側ではマウントされてるようにみえる
Dockerイメージ
・イメージ・レイヤの積み重ね。
・読み込み専用
メタデータのようなものをもつ
Dockerコンテナ
・イメージレイヤを１つのファイルシステムとみなす
・読み書き可能なイメージレイヤを持つ
Dockerイメージは仮想サーバ用のイメージとは違ってプログラムが必要とするファイルしかもっていない
コンテナを実行するときはイメージの上に書き込み可能なレイヤを割り当てている
ログとか。
イメージレイヤには親子関係がある
あるイメージから別のイメージをつくる場合に有効。重複する部分は共有するなどリソースを節約したり差分管理
したり素早く実行したりできる。（gitなどのバージョン管理システムに似てるらしい）
DockerEngineはイメージをコンテナ化してコンテナ技術で動かす
でもコンテナって前からあったよね？Solaris１０とか？
その差とは？
ただコンテナ化して置くだけでなく、
構築・移動・実行（Build>Ship>Run)ができるようになった
移動がHubにあたる。
Dockerイメージの保管と共有をするためのリポジトリ（倉庫）
dockerクライアントがrunをすると
dockerエンジンがhubにイメージを問い合わせて（pull）ダウンロードしてコンテナ追加して実行して返す
イメージは並列で送ったりダウンロードしたりできる
hub.docker.com
CIツールとバージョン管理システムでwebhookでpushしたりもできると。
Dockerイメージ操作コマンド
コマンド体系が最近変わった
最近はイメージにかかわるコマンドは
docker image ～という感じになる
コンテナ操作コマンド
これまではdocker runだったが最近はdocker container runになる
いちばんはじめは
docker image pull
でイメージをhubからとってくる
つぎ
docker image ls
ローカルのイメージを一覧表示
docker container run
イメージを実行
docker container ls
(docker ps)
docker image build
イメージの自動構築（ビルド）
Dockerfileからビルドする
docker container commit
コンテナ用レイヤをイメージ化
docker container inspect
コンテナの詳細情報を表示
docker image inspect
イメージの詳細情報を表示
docker container diff
イメージとの差分を表示
docker image history
イメージレイヤと履歴の表示
docker search
ハブのイメージを検索
コンテナ削除はrm
コンテナもイメージもrmできる
コンテナは動いてるやつをけすやつ
pruneでいらないのを丸ごと削除できる
docker system prune
でいらないすべてを消せる
docker system info
docker system df
キータのzenbutuにのってる
http://qiita.com/zembutsu
コピーオンライトでパフォーマンス劣化
http://docs.docker.jp/engine/userguide/storagedriver/imagesandcontainers.html
デバイスマッパー
ストレージドライバを使うしメモリを食う
使ってるOSのデフォルトで違う
ボリュームはコンテナ用のレイヤとは分離されてるのでデータベースとかで採用するといいかも
docker volume
docker networkなどのコマンドもあるよ
https://www.slideshare.net/zembutsu
@zembutsu
QA
コマンド変わったけど内部的な動きは同じ？
→同じです
----
あさのさん
ECS関連アップデート
AWSのソリューションアーキテクト
アップデート結構多いと。
１２月からのアップデート
ECRについてレジストリの話も
OSSBloxリリース
ECSをカスタマイズしたい人向けのツール
カスタムスケジューラを作りたいとか
WINServerコンテナ対応
タスク定義のいくつか制限など
Hiper-vコンテナはEC2上では動かせない
TaskPlacement
タスクの配置をより柔軟にカスタマイズできる
binpackはタスクをつめこむ
spreadにするとタスクを分散する（AZとかインスタンスとかの指定をすることでコンテナをどこにおくのか決められる）
ECRがDockerイメージ。。をサポート
コンテナインスタンスのドレインをサポート
ほかのタスクに影響を与えずにクラスターからコンテナインスタンスを削除可能に
タスクがいなくなってからホスト削除するとか
コンテナインスタンスのドレイン自動化実装例も
ライフサイクルフックでインスタンスのterminate。waitを検知してSNS経由でlamdaファンクションをinvokeするとか
lamdaファンクションによりコンテナインスタンスの状態を。。うつせず
ECS-optimizedAMIの更新通知がSNSで受信可能に。
リージョン単位
EC2ContainerRegistry（ECR）
つまりAWS上のDockerHubかな
フルマネージドでよい自分らで運用しなくていい
DockerHubは日本にないのでレイテンシが問題
コンテナイメージはHTTPSで送信され保存は暗号化。
IAMとのインテグレーションできるので安全。クロスアカウントもできる
認証用のクレデンシャルヘルパー。使わないとlogin処理が必要になるので手間。
https://github.com/awslabs/amazon-ecr-credential-helper
試してみてね！
----
とださん
コンテナ支部の人
＠thiro1123
とある社内ビックデータ基盤にバッチ用コンテナ環境を構築してみた
会社名は秘密だそうです
導入の背景
バッチが300以上ありサーバ80以上の上に様々なOSやミドルや言語やライブラリやなにやら蜜結合して検証がうまくいかないケースが。
アップデートすると動かないとか日々おこる
事業担当者に怒られるクレームドリブン問題のプロジェクトであった
アラートモニタリングだけで追いつかない
一つのバッチうごかすのに1か月かかる
現在は、新しいことしたらその倍の問題が発生はしない環境
社員の人に「ライブラリの競合がいやならコンテナにしては？」といったら了承3秒。
JP1からバッチ管理したいと。APIゲートウェイつかってる
ラムダ→SQS→ECS
デプロイや環境構築はjenkinsのジョブで自動化してると
QA
・コンテナのイメージ数は？
→オンプレにいるやつもまだいる。データ分析用のやつが２，３個で検証段階
やっとつくったところで絶賛推進中。ほかにも広めてるところ
改善するために分離できるようにがんばっている
・ログをとるとき？コンテナでどうしてる？
→きほんCloudWatchlogsとかS3とかデータベースとか側に送るようにしてる。ボリュームは使わないほうこう
管理が大変になるので
できるだけ状態を持たないようにしてくださいと言ってる
・オンプレのAPIゲートウェイ？
→オンプレのサーバにはなにもいれない。Linuxにはcurlがある。
----
NTTソフトフェアの須藤さん
あさってからNTTテクノクロスにいく
社内研修の講師とか検証とか
社内ではAWSの回し者といわれている。ECSとラムダがすき
NTTとDocker,Containerときいて？
結構深いつながりがある
DockerEngineとetcdとかInfraKitとDockerTokyo OrganizerなどのメンテナとかをNTTのSICから排出してる
わたしは
社内検索エンジンOnDockerをつくったり
備蓄品安心サポートというBtoCのサービスをECS上に構築するなど
ECSの導入メリット
アプリのデリバリサイクルを早める
アプリとインフラの責任分界点が明確、インフラがマネージドサービスになるので劇的に負担が減る
インスタンスとサービスの分離。マイクロサービスの追加がより容易になる。サービスとインスタンスが疎結合になる
サービスを追加するときにやる作業量が減る
価値提供が迅速になる
運用コストを抑えられる。ECS＋SpotFleetと組み合わせると。オンデマンドと比べて51.7%削減した数字を弊PJでもってる
運用オペレーションが簡単になる。人間のオペレーション時間が減るので運用コストが削減される
多くの場合インスタンスよりエンジニアのコストのほうが高い
ECS導入の勘所
なんでも乗せ換えると幸せになるわけでもない。知っておいてほしいことがある。
タスクとかタスクでふぃにしょんとかわからなければブラックベルトの資料みるといいよ
なるべくDockerVolumeを使わなくていいように設計する
Volumeを使うとコンテナインスタンスがImmiutableでなくなるのでクラスタのメリットが損なわれる
ファイルはS3へログはCloudwatchLogsへ永続化データはRDSやDynamoDBへ
ログについてはawslogsというログドライバがあるのでそれを使うのが基本
標準出力をCloudWatchlogsに転送してくれる
ログローテートやログファイルの考慮が不要
fluendとかほかのログドライバの検討
ハイブリッドとかマルチクラウドとかすでに仕組みがある場合に検討するとよさそう
パスの設計（URL設計）
ALBのパスベースルーティングの利用
ドメイン名を分ける必要のないServiceは何か？
多数のサービスがある場合、それと同数のALBを作るとこすとが膨らみやすい
パスベースルーティングで１つのALBに複数のサービスをぶら下げられる
データソース設定
コンテナに埋め込まないですむやつ
環境変数やRoute53のPrivateHostedZoneの利用でRDSのエンドポイントをコンテナイメージに埋め込まないように。
セッション管理
ALBのStickySessionを使う
タスクが停止するとセッションが切れる
SpotFleetだとインスタンスが変わるタイミングは予測できない
頻繁にサービスを更新するような（タスクが停止起動する）場合はこれだけだとつらい
StateStoreを使う構成にする
ElastiCacheでRedisとmemcacheつかうとよい
アプリではspring-boot-starter-redisやSpringSessionなどで
アプリの作りはコンテナベースのサービスに向くか結構重要
環境構築時注意すること
コスト最適化
ECSはSpotFleetとの相性が非常に良い
最新のECS-optimizedAMIを使うとよい
DockerやECSのバージョンアップで更新される
脆弱性対応が通知されたら最優先でクラスタの更新を。
新しいSpotFleetをクラスタに追加
古いインスタンスをすべてドレイン
古いSpotFleetをキャンセル
ECSでのServiceDiscovery
Taskの変動に応じてターゲットグループ（インスタンスとポート）をメンテナスしてくれる機能がある
構築時にしか指定できない
１．からのECSクラスタをつくる
２．SpotFleetをつうｋるインスタンスロールに特定のやつをアタッチしないといけないのとユーザデータでECS_XLUSTERを指定
３．ALBとからのたーぎえっとグループを作る
。。。６つがだいじらしいがうつせず
ポイントを押さえて幸せに
QA
・負荷のところで気になったのがRoute53だとキャッシュとかどんなもんかな
→R53そんなにしらないがプライベートの場合は解決がすごく早いので大丈夫なのでは
→ログの転送がfluentd＋CloudWatchLogsでPrivateHostedZoneで解決して送ってるがログの遅延はロストはない
→DBの場合アプリでコネクションプールしてる場合はトランザクションのたびにDNS引く動きにはならない
----
というわけで備忘録でした。みていただきありがとうございました！
