寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。みんなのウェディングのインフラエンジニア横山です。Docker/kubernetes流行ってますね。弊社でもみんなのウェディングの実行基盤のEKS移行を進めてまいりました。最終的には全てのコンポーネントをEKS上に移行したいですが、最大の難所であるアプリケーションサーバの移行が完了したので、移行を考えた理由、移行への道のりについてまとめます。それはそれぞれ以下のようなメリットがあるためと言われています。Docker環境の可搬性、再現性が高く開発効率が上がる本番、ステージング、開発で同一のイメージを利用することで環境ごとの差異を気にせず開発ができます。意識することなく構成管理が行われた状態を保てるDockerfileをGit管理することで、Itamae,Chef,Ansibleなどの構成管理ツールを使わなくとも構成管理された状態を保つことできます。簡単にデプロイできるDockerデーモンが起動しており、作成したイメージのpullができれば稼働するのでデプロイスクリプトを書いたりといった手間がなくなります。kubernetes宣言的にインフラ構成を管理できるkuberntes上のリソースはmanfestと呼ばれるYAMLファイルで管理されます。このmanifestには起動するコンテナ数などを記載し、kubernetesクラスターに適用します。kuberntesクラスターは、自らの状態が、manifestの定義と乖離した際、自動的に定義状態に収束するような変更を自らに対して行ってくれます。これによりインフラ管理の手間を減らすことができます。意識することなく構成管理が行われた状態を保てるmanfestをGit管理することで、特に意識することなく構成管理が行われた状態を保つことができます。弊社でもこれらのメリットを享受したいと考えDocker/kubernetesへの移行を決定しました。DockerをAWSで動かしたい場合、ECS/EKSという2つの選択肢があります。ECSは確かにシンプルで良いサービスです。弊社でも利用しています。AWS上で初めてDockerを運用したいという場合、最適なサービスだと思います。ECSにはAWSへのロックインというデメリットがあります。今後、状況が変わった時に他社サービスに移行するということもあるかもしれません。社員自身も今後AWS以外を利用する場合があるかもしれません。そこで、kuberntesへの理解を深め、社員が保有する技術スキルの多様性を保つ意味でEKSを選びました。移行への道のり移行の具体的な手法についてはアプリケーションごとの特性もあるためここでは大まかにやったことを記載しておきます。設定にもあるように、設定を環境変数に格納することはできていましたが、一部の環境変数がインフラ側でitamaeを使って構成管理する形になっていました。Docker化するにあたり、これらの環境変数をアプリケーション側で管理するように変更しました。秘匿すべき情報に関してはyaml_vaultを利用してアプリケーション側で暗号化しています。弊社ではもともとZabbixを利用して監視をしていました。ZabbixでもDocker/kubernetesの監視はできそうでしたが、監視に関してはマネージド化して運用工数を下げたいという思いもあり、Datadogに移行しました。デプロイフロー構築デプロイフローの構築にはArgoCDを利用しました。初めはSpinnakerで構築していたのですが、以下のような課題がありArgoCDに変更しました。ChatOpsとの連携が難しい弊社では、Slackのスラッシュコマンドを利用して本番環境へのデプロイを行っています。デプロイを実行する方法を探したのですが見つかりませんでした。kustomizeが使えない※現在は使えるようになってるようです。https://www.spinnaker.io/guides/user/kubernetes-v2/kustomize-manifests/デプロイフローを構築している当時(10月ごろ)は使えなかったので、これもArgoCDへの変更を考える理由の1つでした。ArgoCDを使うと、上記の課題は解決されます。Git上のmanifestを自動的にkuberntesクラスターに適用してくれるため、スラッシュコマンドの処理の中で利用するイメージを変更するコミットをGitHubのmasterブランチにpushするだけでデプロイが実行されます。manifestはkustomizeを使うことで冗長にならずに記載することができ、ConfigMapのバージョン管理もkustomizeが行ってくれます。https://github.com/kubernetes-sigs/kustomize/blob/master/examples/configGeneration.mdSecretsに関してはSealedSecretを導入して管理しています。https://github.com/bitnami-labs/sealed-secretsまとめ移行後、今のところ大きなトラブルもなく稼働しています。今後、Rubyのアップデート対応やミドルウェアのアップデートを行う際に、移行前の工数と比較してみたいと思います。手前味噌ですが、みんなのウェディングは色々チャレンジができて本当に良い会社だなと思います。(2019年12月21日)twitterfacebookhatenabookmark最新の記事みんなのウェディングはEKSで動いていますタイポグラフィとCSSのスタイル宣言2019年新卒エンジニア研修もそろそろ終盤です。