## 狙い - Kubanetesの知見をいれる ## 実施内容 - OCIのOKEを利用する - Gitに履歴が残る形にする - [x] gitlab.avaper.day - [ ] id.avap.co.jp - [ ] ldap.avap.co.jp - [x] register.avaper.day - [ ] pages.avaper.day - [ ] grafana - [ ] prometheus - [ ] admier / phpmyadmi とか。 DBever用のproxyとかでもいいかな - [ ] loki - [ ] m3db cluster (これは難しいかもしれない) ## 方針 ### 技術力を落とさない程度に楽をする Helmでそのままインストールすると、理解度合いが確認できないので、以下で実行する - HelmのIngressは使わない - PostgresqlはAivenを使う - GitalyはClusterにする - gitlab-runnerは分離して導入する - D in D 版のDockerを分離し、gitlab-runnerでci/cdができるようにする - 既存のhostkeyとKubernetesのhostkeyは一致させる ### サービスの設計として - ベース部分 (IngressなどKubernetes環境とinternetの境界設計) - 永続部分 (ブロックボリュームやNFSなど) - namespace (領域の一括管理として) - helm / kusotomize (サービスの管理方式) ここまでは基本的に設計すべき 以下、個別 - それは、どこから参照されるか 公開/内部 - 専用のIngressが必要か (必要に応じて Avap NginxとNLBを連携させる) - 永続化する部分はどこか（NFSやブロックボリュームなど設定する) - 利用する機密情報はなにか？どう管理するか？ (1passwordとか連携するのも多分可能) ### 急ぎめ - リソース監視を導入する必要あり。 - （アバップの全システムをkubernetesにのっけたい） - 各リソースのバックアップをし、再配置プランを立てた上で実施する必要がある ## メモ - db名が変わるとrestoreできない - omnibus版と違って、s3cmdのconfigを直指定する必要がある - secretはだいぶ、個別に設定する必要がある - basedomain + サブドメインの構成が基本っぽい - postgressもクラスタに入れると、ハードウェア要件があがる - terraformで管理するのはあまり現実てきではない ## 推測 - prometheusやnode exporterなど監視系はoperatorを使うことで、コンテナを簡単にdiscoveryできるところがメリット - helmの使い方を覚えるとできそう。ただし、細かい作業が必要なものはKustomizeが便利 ## 課題 - TerraformとKubernetesの連携(Helmの作成の自動化とかか？)