## GitLab Auto DevOps & k8sを<br>オンプレ環境に構築してみた [\@GitLab Meetup \#9](https://gitlab-jp.connpass.com/event/92996/) 小林　寛明 三好　俊介 --- ### 免責事項 ```Java 本発表の内容は、個人としての意見であり、 所属する会社/組織としての意見/見解を代表するものではありません。 ``` ### ご留意事項 * 少し古いOSSを使っています * GitLab 10.6.5 * k8s v1.10.0 --- ## 自己紹介(小林 寛明) * 所属 * 富士通株式会社 * サービステクノロジー本部 * 経歴 * Javaアプリのフレームワーク開発(10年) * GitLabの社内展開業務(いまここ) Note: 富士通の方から来ました。 社内SEに向けて有益な情報を展開していく部署ではらたいています フレームワーク開発やってましたが、今はGitLabの社内展開やってます ---- ## 弊部のGitLab関連の取り組み  Note: GitLab + その他もろもろのツールを疎結合したcomposeを「社内に」展開 使い方(特にツールのというよりは、プロセス周り)の資料とか研修も展開 社内コミュニティみたいのもやってます --- ## 自己紹介(三好 俊介) * 所属 * 富士通株式会社 * Linux開発統括部 * 経歴 * Kubernetesコミュニティエンジニア * オンプレ向けCICD環境の構築(主にCD担当) * その他 * Certified Kubernetes Administrator * 休日もコード書いてたりします(・ω・)b Note: 今回は技術面から小林さんをサポート --- ## 弊社独自の背景 * 開発/運用環境はオンプレが多めです * お客様も * 弊社自身も なので… * インターネット上の便利なサービスを 使えない事が多いです * GitLab.comとか * GKEとか --- というわけで本日のお題 ## ｵﾝﾌﾟﾚでAuto DevOpsしてみた  Note: オンプレ環境下で、GitLabに対してk8sを繋げてAuto DevOpsしてみる、 というのをやってみました。 ここでポイントは2点 ・全部オンプレ（社内ネットワーク) ・社内ネットから外へのアクセス時にはプロキシがある ・k8sクラスタも自前で作成(パブリックのクラスタを使たかったけど…) で、この辺ではまりポイントとか、感想を説明します ☆ここから三好さんにバトンタッチ。 --- ## Auto DevOpsについて Auto DevOps自体の紹介については、 既存の素晴らしい記事/動画があるので、 そちらをご参照ください！ * [GitLab Auto DevOps を試してみた \(その一\)](https://qiita.com/masakura/items/2a23b3c02529b77ba5d3) * @masakuraさんの記事 * [めちゃくちゃ分かり易いデモ動画](https://www.youtube.com/watch?v=6LZQCCVGVDg) * GitLab公式 --- ## あじぇんだ * はまりポイントと攻略方法 * 感想 * 結論 * GitLab Inc.の皆様へ --- ## はまりポイント その1 ### 「k8sクラスタを自前で組むのは辛い」 ---- * k8sだけでなく別OSSと連携必須 * docker * CNI(Flannel, Calico, ...) * 設定項目(セキュリティ等)が多い * 柔軟な設定が可能 * どう設定すればいいかわからない <u>**→ kubeadmの利用**</u> Note: kubeadmはデフォルトでセキュアなクラスタを作成してくれる prerequireが非常に少ない(サーバスペックとOSくらい)ので基本的にどこでも構築できる ---- * はまり：k8sクラスタに追加で↓が必要 * [Ingress Controller](https://github.com/sh-miyoshi/sectest/blob/master/system/ingress-controller-nginx.yaml) * Ingress本体はAutoインストール可能 * ただし、野良k8sクラスタの場合、Controllerは自前で用意する必要有 * [DefaultStorageClass](https://qiita.com/teruq/items/17609eecc29b70e2cbe7) * 野良k8sクラスタの場合、自前で用意する必要有 * 攻略法 * あらかじめ手組で作っておく * 内容は上記のリンクを参照！！ Note: Ingress Controller, DefaultStorageClassが必要と分かったのは実際にやった見てエラー結果を分析したから(ドキュメント等はない) --- ## はまりポイント その2 ### 「たちはだかるプロキシの壁」 ---- ### "Kubernetes" behind Proxy * はまり * docker pull等の外部通信はプロキシ経由 * クラスタ内通信はプロキシを経由しない様に * 攻略法(?) * no_proxy * k8sのServiceのすべて(例:10.244.0.0/16)を設定する必要あり * no_proxyはワイルドカード書けない！ (10.244.0.1,10.244.0.2,...) ---- ### "Kubernetes" behind Proxy * 攻略法 * ローカルプロキシ(Squid)を立てる <small>参考(https://github.com/sh-miyoshi/local-proxy)</small>  ---- ### "AutoDevOps" behind Proxy * はまり * そもそも[Proxy未対応](https://gitlab.com/gitlab-org/gitlab-ce/issues/46366) * 攻略法 * k8sのPodPreset機能で、自動配備されるPodにプロキシ情報を渡す vi /etc/kubernetes/manifests/kube-apiserver.yaml ```yaml ・・・ spec: containers: - command: - kube-apiserver - --runtime-config=settings.k8s.io/v1alpha1,api/all - --admission-control=...,ResourceQuota,PodPreset ・・・ ``` ---- <div style="text-align: left">（つづき・・・）</div> kubectl create -f proxy-preset.yaml ```yaml apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: proxy-preset spec: env: - name: http_proxy value: "http://<your-proxy>" - name: https_proxy value: "https://<your-proxy>" - name: no_proxy value: "10.96.0.1" ``` --- ## はまりポイント その3 ### Permission denied... ---- * はまり * GitlabのPrivate Registryはhttpでも docker loginが必要(pushもpullも！) * 攻略 * insecure registryの設定 + Kubernetes向けのregistryの認証情報を設定 ``` vi /etc/docker/daemon.json ``` ```json {"insecure-registries": ["<your-registry>"]} ``` ``` kubectl create secret docker-registry autodevops --docker-username="user-name" --docker-password="passwd" --docker-email='test@example.com' --docker-server="<registry-url>" ``` ---- * はまり * kubernetesのデフォルトの権限(Service Accountの権限)ではgitlab-runnerが動けない * 攻略法 * k8sの設定を変更(Podの作成権限を追加) kubectl create -f rolebinding.yaml ```yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: RoleBinding metadata: name: autodevops roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin subjects: - kind: ServiceAccount name: default ``` ---- * はまり：[AutoDevOpsがRBAC未対応](https://gitlab.com/gitlab-org/gitlab-ce/issues/44597) * 攻略法：ABAC認証で暫定対処 vi /etc/kubernetes/manifests/kube-apiserver.yaml ```yaml ・・・ spec: containers: - command: - kube-apiserver - --authorization-mode=Node,RBAC,ABAC - --authorization-policy-file=/etc/kubernetes/pki/kube-abac-gitlab.json ・・・ ``` --- ## 感想 その1 ### 「自動インストール機能はロマン」 * 各種ツールをk8sクラスタに1Clickで追加できる * GitLab CI Runnerとか * Ingressとか * Prometheusとか * 特にRunner追加が楽になるのは嬉しい！ ---- # ただし # ちゃんと動けば… ---- ## 分かる人には分かる、あの画面  Note: 自動インストールに失敗するとこの画面が出ます。 ほぼほぼこの画面との闘いでした…。 --- ## 感想 その2 ### 「Auto Review Appsは神」 ブランチを切ると「自動的に」k8sクラスタに * ブランチ毎の動作確認環境を構築してくれる！ * Ingressで各環境のURLを設定してくれる！ これにより * 動作確認環境の構築/メンテがめっちゃ楽 * 作ったアプリを「気軽に」動かして見れる ---- ## SIerさん的には…  Note: SI案件ではテスト/動作確認/デモ環境が山ほどあるケースが多いです この辺がAuto Review(というかk8sへの自動配備)で もんんんんの凄く楽になります！ --- ## 感想 その3 ### 「Staging/Production環境への ### 自動デプロイ/監視機能は素晴らしい」 MRで全ての情報を一元的に確認し、 ワンぽちでデプロイできます！ * 機能/非機能検査の結果とか * 静的/動的解析の結果とか クラスタの監視情報(CPU/MEM等)も、 GitLabの画面からぱっと見る事が出来ます！ ---- ### だがしかし SIerさん的には、本格適用への道はまだ遠いかも… * k8sの本番環境への導入を検討してくれるお客様は、現時点では少ない * 社内でもk8sのスペシャリストが少ない * 社内でk8s関連のノウハウがまだ浸透していない --- ## ちょっとつらかった… * Autoインストールでエラーが多発 * これは今後の改版に期待 * Pipeline実行に時間かかる(資産を毎回DLする) * 各種ｷｬｯｼｭは自前でチューニング必要かも * Docker in Dockerで使うイメージとか * インターネットからDLするライブラリとか * インターネットからDLするツール(SAST等) --- ## 結論！ * Auto DevOpsは凄くいいです * 将来性/拡張性があり、素敵な機能と思います * k8sのフル活用が難しいSI案件においても、 部分的に使える機能は多数あります * ただ、野良のオンプレk8sクラスタに繋ぐのは、「現時点では」少しﾂﾗｲかも… --- ## 最後に「GitLab Inc.の皆様へ」 * 社内プロキシの壁に阻まれながら、 * 社内ネットワークの内側で、 * 開発している人たちの事、 時々でいいので思い出してあげてください。 ---- ## Last AND Least I pray for that... Someday, God save all developers who are * Straggling with the wall of proxies and * Unable to use public cloud services  --- ## おわり ご静聴、ありがとうございました！！ Thanks much for listening!! --- Shaping Tomorrow with You