WSL2でDockerを動かす

f:id:translucens:20200609011257p:plain

Windows 10 May 2020 Updateが正式に公開され、Windows Subsystem for Linux (WSL) が2になってDockerとの互換性が向上したとのことだったで試しました。

TL; DR

WSL1での辛み(DockerがUbuntu16.04では動くが18.04では動かなくなってしまう、ファイルアクセスはWindows側のNTFSへ読み替える都合でパフォーマンスが出ない等)は解消され、Linuxでの実用的な開発環境として使えるようになりました。

続きを読む

Kubernetes Meetup Tokyo #21 - Cloud Native CI/CD 参加レポート

Kubernetes Meetup Tokyo #21 - Cloud Native CI/CD にブログ枠で参加しましたのでそのレポートです。 k8sjp.connpass.com

セッション内容

Argoプロジェクト最新動向

www.slideshare.net

PFN @dtaniwaki さんの発表。

普段はジョブスケジューラ、クラスタ向けツールの開発をされているそう。

Argoプロジェクトとは?

intuit社のワークフローが起源 BlackRockの別プロダクトがEventsにリネームされ、合流して今に至る

名前はギリシャ神話(巨大な船)から、Kubernetes関連ツールをたくさん載せようというところから来ている PFNのクラスタ要件に見合わない点があり、2018年半ばからコントリビュートを続けているとReviewer→Approverになった

Argo Workflows

複雑なフローを組める S3, HDFS等のストレージからの入出力に対応 パラメータ展開により、複数Podで同じテンプレートの再利用ができる。また同時実行数の制御も可能

Workflowsの新機能と使用例

  • v2.3
    • Kubernetes APIベースのExecutor: Dockerdへ直接アクセスしなくてよい
    • テンプレート展開によって生成される多数の実行履歴を圧縮: etcdに生で保存していると上限にかかって実行できなかったができるようになった
    • InitContainer: データセットをロードする
  • v2.4
    • ステップ実行履歴の圧縮でも上限は(上がったとはいえ万単位だと上限に当たる)あるのでRDB等、外に保存
  • v2.5
    • Argo独自のAPIサーバ: kubectl getで取れなくなる(etcdに保存しない場合)情報を代わりに提供

Argo CD

  • Git管理のマニフェストのデプロイに特化、Spinnaker等汎用ツールと比べてKubernetesを使うのであればできることが多い

  • GitOps関連の特徴

    • リソースの一部のみデプロイ・ロールバックできる
    • 緊急用にGitOpsでなく手動でパッチを当てることもできる
    • 複数のマニフェストテンプレートエンジンをサポートするので、YAMLを事前に展開しておく必要はない
  • UI

    • InitContainerやSidecar,Ingress, Serviceも画面から見られる
  • 拡張性

    • Kubernetesデプロイの各フェーズでフック可能
    • CIと連携したい場合はCLIを使用する
  • CDに特化しているのでSaaSやJenkins等でCIは事前にしておく必要あり *マニフェストの変更検知から始まる

CDデモ

  • Projectsは元となるのGitリポジトリと適用先のクラスタを組にしたもの。プロジェクトを単位としてRBACで権限管理できる

  • プロジェクトにアプリケーションを登録する。今回のデモではhelm-guestbookが使われていた。マニフェストの同期は手動にすることもできる。ソースのブランチやパスも設定することが可能

  • 画面ではアプリケーションに含まれるDeployment, Service…、その配下のPod…を階層構造で見られる。Out of Syncの場合は、画面にマニフェストのdiffが出るので差分を容易に確認できる

Rollouts

ストラテジーを指定したデプロイが可能になる。 KubernetesのDeploymentが標準でサポートするrollingUpdateとRecreate以外の方式が必要な時に使用する。具体的にはBlue/GreenとCanaryが利用可能。

今後ABテストができるExperiments CRDが追加される予定。良かった方を選ぶストラテジーとしてRolloutsに指定することもできるようになるそうだ。

会場からの質問

  • 今の実装だとCloudEventsは0.1対応だが、CloudEvents (v0.2, 0.3) への対応予定はあるか
  • デプロイ直後にテストを実行するにはCI等外部の仕組みが必要か?
    • フック機能があるので、AfterSyncにテスト用のPodを指定すればよい
    • 同じディレクトリにテスト用PodのManifestを置いておき、アノテーションを付ければフック時のみ生成できる。
    • テスト結果に応じてCLIからresumeをするのも可能

GitOpsでも秘匿情報をバッチリ扱う方法、SealedSecretsとは?

speakerdeck.com

さくらインターネット @amaya382 さんの発表

自己紹介の後、参加者にアンケートが取られた。

  1. k8s触ったことない: 数名
  2. k8s触ってるけどGitOpsはまだ: 半分くらいで一番多い
  3. GitOps試してる: 上ほどではないが多い
  4. GitOpsがっつり: 数名

GitOpsでは、GitリポジトリがSingle source of truthになるのでSecretもGitリポジトリに載る。仮にプライベートリポジトリだったとしても、平文で機密情報が載るのは好ましくない。これを解決するためにSecretマニフェストの暗号化ツールSealedSecretsを使う。

github.com

SealedSecretsについて

  • 生のSecretsの代わりにCRD: SealedSecretリソースを使う
  • 公開鍵暗号を使って暗号化
  • SecretsだとBase64で保存されているデータ部が暗号化されている

  • 24日0.8.0リリース、開発は活発な印象

使い方

  1. kubeseal CLIで平文のSecretをSealedSecretsに変換し、Gitにpush
  2. CDツールがマニフェストの追加を検知し、SealedSecretsリソースを作成
  3. SealedSecretsからSecretへの復号はクラスタ内で自動的に行われる

利点

  • ユーザは暗号化鍵の存在を意識しないでよい
  • Podからは既存のSecretとして使える

欠点

  • 暗号化はCLIを使って手動で行う必要がある
  • テンプレートエンジンとの相性悪め

補足

  • GitOpsで機密情報を暗号化するもの。クラスタには従来通り平文のSecretができる。Secretへのアクセスは制限する必要がある
  • etcdの暗号化はスコープ外: EncryptionConfiguration等、別の仕組みで暗号化設定が必要

テンプレートエンジンとの併用

秘匿情報は環境別のパッチファイル側に含まれるべき内容。一方でSealedSecretsは完全な(テンプレでない)Secretをベースに生成するので競合する。

  • ワークアラウンド
    • 完全なSealedSecretsを含めてしまう
    • 頑張って差分を取る
    • ツール対応を待つかコントリビュート

最後に、類似、関連する各種ツール群が紹介された。特定のテンプレートエンジンを使うか、汎用性を求めるかのトレードオフで選択肢が変わってくる印象を受けた。

質問

  • SealedSecretsで暗号化するとき、クラスタへアクセスできない人は公開鍵をどう入手すればよいか?
    • 鍵ペアは手元にバックアップする機能があり、CLIでローカルの鍵を指定できるので、それで暗号化できる
  • 暗号化したユーザ以外が(レビュー時に)その中身を確認することはできるか?
    • シンプルさを重視しており、鍵ペアは一つ。デプロイされてControllerがSecretを作るまで平文の値は分からない
  • 意図しない値にならないよう運用で気をつけていることは?
    • テスト環境を別途用意してそこで動作は確認している

コロプラが実践しているSpinnakerを用いたデプロイ戦略

speakerdeck.com

コロプラ @go_vargoさんの発表

Spinnaker for GCPは今日は触れないが記事があるそうだ qiita.com

構成

  • フロントがUnity、アセット保存にAmazon S3、アプリがGKEの構成。
  • ゲームタイトルとクラスタが1:1、モノリシックな構成。
  • Spinnakerもクラスタ=タイトルの数と同じだけある

GKE, Spinnaker, GitLab CI, Helmを組み合わせている。

Spinnakerとは

Kubernetes実践ガイドが日本語で書かれた詳しい資料である。

Application / pipeline / job の階層構造を持つ。

  • Spinnakerは汎用ツールでVMにも対応しているので、SpinnakerでいうCluster→KubernetesのDeployment のように用語が一致しないので要注意
  • Blue/Green, Rolling Update, Canary Releaseに対応
  • SpinnakerもマイクロサービスでGroovy製

実際の構成

CIの中でHelmテンプレートをGCSに置き、SpinnakerはGCSを参照する

カスタマイズ、セットアップ

  • Halyardを使ってカスタマイズを入れている。HA構成
    • Clouddriver: RW, R, Cacheのように分割
    • Redisも複数台構成にしている
  • Spinnakerのパラメータもチューニングしている
    • kubectlのタイムアウトがデフォルトだと時間がかかってエラーになることがあったので伸ばした
    • 画面表示の上限も引き上げ
    • Dockerイメージタグの上限もエラーが起きるので増やす
    • なおデフォルト値はマニュアルにはなく、ぐぐっても出てこない
  • Spinnakerの認証はGSuiteと連携し、Google Groups単位で権限を割り当て
    • 参考: Fiatは他にもLDAPGitHub等に対応

開発環境の分離

ゲーム固有の要件として、ゲーム内イベントごとに環境を分ける必要があり、かなりの数を作る必要がある。以前はその準備に数日かかっていた。

Gitのブランチ作成をトリガーとして、新しいNamespaceを作成し、その中に環境が作られるようになっている。

闇とその対応

  • 挙動が不安定→GCPAPIタイムアウト: Clouddriverを再起動する
  • ローカルにSpinnaker環境を作って、GroovyをIntelliJデバッグ

  • ServiceAccountが環境を消したときにまだ必要なのに消されてしまう(仕様)

  • アプリエンジニアには概念がよくわからない、昔は直接SSHできたのにとの声が聞かれるので、その解消も検討中

質問

  • パッチバージョン数日ごとに出るけどどうしてるの
    • 初期に作ったv1は見放している面があるが、それ以外のv2では追従している。検証環境で調べて順次ロールアウトしている。
  • dev環境作るときにnamespaceで分離とのことだが、nsだけでは衝突するリソースの扱いはどうしているのか
  • ノイジーネイバー問題はどうしているか
    • 基本はオートスケール、問題が起きたらインフラエンジニアで対応
    • ResourceLimitは設定済み
    • 一年やって経験が溜まってきたので、既知の課題は解消できるようになっている

LT

Argo CD 実践ガイド

dev.classmethod.jp クラスメソッドの@ponde_mさんの発表

時間の関係でRBACは話されなかったが、資料には書いてあるので確認したい。

Flux/Flaggerでカナリアリリースする

@Shoheheさんの発表

FluxはGitHubYAML更新を監視し、更新する FlaggerはPrometheusのメトリクスを定期的に見て自動的に新しいバージョンの割合を増やしていく。

KubeflowPipelineを用いた機械学習ライフサイクル

@me7te7orさんの発表

タクシー事業で、客が多そうなルートを推薦する仕組みを機械学習で行っている。

  • 課題

    • 複雑なフローでヒューマンエラー
    • モデルの劣化(施設の閉館)
    • 複数の実験とファイルに書かれたパラメータの取り違え
  • Kubeflow pipeline

    • UIでコンテナの依存関係を組んでいく
    • 自動デプロイで常に更新、モデルを更新
    • 日次で更新、Composer使う
    • 実験のパラメータの管理:パラメータを表で比較することができる

詳しくはCloud Next Tokyoのセッションにて発表される予定。

Vault on Kubernetes

speakerdeck.com @kennygt51さんの発表

機密ストレージVaultをKubernetesの上に置いて使っている。 マスターキーのAuto UnsealingにはAmazon KMS、データを保存するバックエンドはDynamoDBの組み合わせで使っている

CLIツールGitHub - hashicorp/envconsul: Launch a subprocess with environment variables using data from @HashiCorp Consul and Vault.を使うと、Vault内の機密情報をマウントした状態でアプリを起動することができる

所感その他

途中のアンケートの結果でもあったように、GitOpsを試している段階の人が半数程度、自分含めまだ試せていない人も多く、これから発展していく分野なのだろうと感じる。 Argo CDのきれいな画面は魅力的。機密情報はIAM RoleやService Accountのようなクラウドサービスの機能を使ってできるだけ減らしたいが、外部のAPIキーやSlackのWebhook URLの扱いで必要になりそうなので、今回の発表が役立ちそうだ。

今回は紹介されなかったがTektonやJenkins X、それらが含まれるCD Foundationも動向を追いつつ、実環境に導入していきたい。

cd.foundation tekton.dev jenkins-x.io

Cloud Build内でCLIツールを使う

Google Cloud Platformのビルドサービス、Cloud Buildは複数のコンテナを連携させてビルドしていくのが特徴です。 各ビルドステップは異なるコンテナで実行され、次のコンテナへ引き継ぐ際にワーキングディレクトリ以外のファイルは破棄されてしまうので、他のビルドサービスのようにビルド事前ステップでパスの通った場所にインストールしておいて、次のステップで使うことはできません。この制約をNode.jsとPythonCLIツールを使う場合に解消する方法です。

大手クラウドCLIツール

三大クラウドCLIツールはそれぞれ公式にDockerイメージが提供されているため、独自にインストールしなくてもそれを使うことができます。

Node.jsベースのツールのインストール

静的Webサイトジェネレータ hexo を例にします。

hexoの公式サイトでは、 npm install hexo-cli -g のようにCLIツールをグローバルインストールして使うように書かれています。

単にローカルにインストールするとCLIを使うときのパスが長くなってしまうので、タスクもpackage.jsonに追記することで npm run hexo ... のように簡潔にhexoのCLIを呼び出せるようにしました。

初めにpackage.jsonに追記して

{
  "name": "Hexo_site",
  "version": "0.0.0",
(略)
  "devDependencies": {
    "hexo-cli": "1.1.0"
  },
  "scripts": {
    "hexo": "hexo"
  }
}

Cloud Build内で npm install --no-progress を実行して、必要なパッケージ群をインストールします。

次のステップで、hexo generateの代わりにnpm run hexo generateを実行すればHTMLファイルが得られます。

Pythonベースのツールのインストール

AWS CLIを例にします。これもNode.jsと同じように、/workspaceにインストールします。 環境変数 PYTHONUSERBASE=/workspace を設定した上で、pip installを実行します。

pip install --user --progress-bar off awscli

こちらは/workspace/bin/aws s3 ...のように実行することができます。

補足: AWS認証情報の保存

AWSのIAMシークレットは安全に保存しておく必要があるので、Cloud KMSを使って暗号化し、Cloud Buildのビルド時に復号して使うようにします。Google Cloudの「Step3. Cloud KMSでトークンを暗号化」の記事を見てください。

GitLabの外部リポジトリへの同期機能を使ってクラウドのGitリポジトリと同期する

GitLab CE 10.8の新機能として、外部リポジトリへのプッシュ機能が無償版でも使えるようになりました

用途としては、GitLabのリポジトリのバックアップとしてパブリッククラウドのGitを使う、クラウド側のCIサービスとの中継点として使用する等が挙げられます。

GitLabの設定

プロジェクトの管理権限を持つユーザで、 SettingsRepository を開きます。

f:id:translucens:20200326012801p:plain
GitLab: Push to a remote repository

続きを読む