NoFWL ChatGPT Desktop applicationでのuser custom promptのショートカット設定方法
NoFWL ChatGPT について 今話題の ChatGPT、皆さんはどちらをお使いでしょうか？ openAI 公式の chatGPT もいいのですが、Prompt Design をする人からすると、自分が作ったプロンプトを毎回コピペしなきゃいけないので少し不便になります。 そこで使うのが、NoFWL の ChatGPT です。 こちらは、デスクトップアプケーションとして提供されており、見栄えも openAI のものとさほど変わりませんが、Awesome Prompt Engineering の GitHub リポジトリと連携されており、事前に用意されているプロンプトテンプレートを簡単に使うことができます。 また、チャットのマークダウン出力、画像出力、PDF 出力が提供されていることも魅力的です。 今回はその中でも、自分で作った Prompt Design をショートカットとして登録する紹介をします。 Install 各 OS インストールについてこちらで紹介していますので、事前に行なってください。 自分は MacOS で HomeBrew を使ったインストールを行いました。 brew tap lencx/chatgpt https://github.com/lencx/ChatGPT.git brew install --cask chatgpt --no-quarantine 自分が作ったプロンプトをショートカットに設定する。 アプリケーションインストール後、アプリケーションを起動して Mac の上部ヘッダーの「Preferences」→ 「Control Center」をクリック。 そうすると、設定画面が開かれるので「Language Model」→ 「User Custom」にいき、「Add Model」により、自分のプロンプトを追加することができます。 自分は以下の画像のように設定を追加しました。 追加が完了すれば、後は/your_command で呼び出せることを確認して完了です！
GKE Connection GatewayとArgoCD ApplicationSetによるアプリケーションデプロイ
GKE に欠かせない CD ツールの一つである ArgoCD。 クラスターが一台の時はいいのですが、これが複数台になった時にどのように管理しようか悩みました。 耐障害性観点から複数台に分けてインストールするのもありですが、一台にプロジェクト間を跨いだクラスター管理をして管理コストを下げたらいいなとも思いました。 調べる前は VPC のピアリングなど修正する必要があるなーと思いましたが、GCP で提供している Connection Gateway を参考にネットワーク依存せずに一括にクラスター管理ができそうだったのでこちらを試してた時の備忘録です。 Terraform で GKE リソースの作成 下記内容で GKE リソースを作成します。※Autopilot です。 locals { name_prefix = "test" project_id = "your-project" } data "google_client_config" "default" {} data "google_project" "project" { project_id = local.project_id } resource "google_container_cluster" "test-1" { provider = google-beta project = local.project_id name = "test-1" location = "asia-northeast1" # Enable Autopilot for this cluster enable_autopilot = true ip_allocation_policy {} release_channel { channel = "REGULAR" } } resource "google_container_cluster" "test-2" { provider = google-beta project = local.project_id name = "test-2" location = "asia-northeast2" # Enable Autopilot for this cluster enable_autopilot = true ip_allocation_policy {} release_channel { channel = "REGULAR" } } # Register to Fleet resource "google_gke_hub_membership" "fleet-1" { membership_id = "test11-fleet" project = local.project_id authority { issuer = "https://container.googleapis.com/v1/${resource.google_container_cluster.test-1.id}" } endpoint { gke_cluster { resource_link = "//container.googleapis.com/${resource.google_container_cluster.test-1.id}" } } } resource "google_gke_hub_membership" "fleet-2" { membership_id = "test12-fleet" project = local.project_id authority { issuer = "https://container.googleapis.com/v1/${resource.google_container_cluster.test-2.id}" } endpoint { gke_cluster { resource_link = "//container.googleapis.com/${resource.google_container_cluster.test-2.id}" } } } クラスター、fleet の存在を確認する。 gcloud container clusters list gcloud container hub memberships list ArgoCD のインストール kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}' kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ConnectionGateway の設定 Connection Gateway 用の Service Account,Workload Identity のリソース追加 module "sa_cluster_argocd_admin" { source = "./modules/service_account" project_id = local.project_id account_id = "argocd-fleet" display_name = "argocd-fleet" description = "Argocd cluster" roles = ["container.admin", "gkehub.gatewayEditor"] } module "workload_identity_argocd_server" { source = "./modules/workload_identity_iam" project_id = local.project_id gcp_service_account_id = module.sa_cluster_argocd_admin.name k8s_service_accounts = [ "argocd/argocd-server", "argocd/argocd-application-controller" ] } modules/resource の内容 resource "google_service_account" "service_account" { project = var.project_id account_id = var.account_id display_name = var.display_name description = var.description disabled = var.disabled } resource "google_project_iam_member" "service_account_iam" { project = var.project_id for_each = toset(var.roles) role = "roles/${each.key}" member = "serviceAccount:${google_service_account.service_account.email}" } locals { annotations = formatlist( "serviceAccount:${var.project_id}.svc.id.goog[%s]", var.k8s_service_accounts, ) } data "google_service_account" "serviceaccount" { account_id = var.gcp_service_account_id } resource "google_service_account_iam_binding" "wi_iam_binding" { service_account_id = data.google_service_account.serviceaccount.name role = "roles/iam.workloadIdentityUser" members = local.annotations } Google Service Account の追加が確認できたら、Kubernetes Service Account リソースを追加します。 --- apiVersion: v1 kind: ServiceAccount metadata: annotations: iam.gke.io/gcp-service-account: argocd-fleet@$PROJECT_ID.iam.gserviceaccount.com name: argocd-application-controller --- apiVersion: v1 kind: ServiceAccount metadata: annotations: iam.gke.io/gcp-service-account: argocd-fleet@$PROJECT_ID.iam.gserviceaccount.com name: argocd-server ArgoCD で管理したいクラスター secret を記載します。 apiVersion: v1 kind: Secret metadata: name: test2-gke labels: argocd.argoproj.io/secret-type: cluster type: Opaque stringData: name: test2-gke server: https://connectgateway.googleapis.com/v1beta1/projects/$PROJECT_ID/locations/global/gkeMemberships/$FLEET_NAME config: | { "execProviderConfig": { "command": "argocd-k8s-auth", "args": ["gcp"], "apiVersion": "client.authentication.k8s.io/v1beta1" }, "tlsClientConfig": { "insecure": false, "caData": "" } } 内容に問題がなければkubectl applyをします。 アプリケーションリソースと ApplicationSet の作成 アプリケーションリソースは Nginx コンテナ利用しています。 ディレクトリ構成はクラスタ別に分けて Kustomize で管理していることを前提にして、ApplicationSet を作成します。 ※アプリケーションリソース省略 apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: dev-backend spec: generators: - list: elements: - cluster: test1-cluster url: https://kubernetes.default.svc - cluster: test2-cluster url: https://connectgateway.googleapis.com/v1beta1/projects/$PROJECT_ID/locations/global/gkeMemberships/$FLEET_NAME template: metadata: name: "-nginx" spec: project: default source: repoURL: https://github.com/$GITHUB_USERNAME/REPO_NAME.git targetRevision: HEAD path: "nginx//overlays/dev" destination: server: "" namespace: default 問題なければkubectl applyをします。 apply を行うと ArgoCD のダッシュボード UI にアプリケーションが二つ登録されていることが確認できます。 念のため、各クラスターからアプリケーションが作成されてるか確認しましょう。 kubectl config use-context test-1 ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 2/2 2 2 6m29s kubectl config use-context test-2 ➜ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 2/2 2 2 4m46s Connection Gateway を利用してネットワークの設定いじらず、簡単に ArgoCD でプロジェク間クラスターの管理ができるようになりました。 この他にも手動 fleet 登録を活用することによって EKS,オンプレ K8s の管理もできるようになったので、積極的に活用していきたいですね。
GKE MultiClusterIngressを使用した独自ドメインとSSL設定
MultiClusterIngress について MultiClusterIngress は Google Kubernetes Engine(GKE)が提供が提供するクラウドホスト型のコントローラーです。 特にクラスタを複数用いた冗長構成に使用したりします。 ただ、通常の Ingress コントローラーとは違い Annotations に制限があるため、今回は MultiClusterIngress での独自ドメインと SSL 設定を行う方法を記します。 前提条件 独自ドメインを持っていること。(今回はお名前.com で取得したドメインを使用します。) GKE MultiClusterIngress,MultiClusterService の環境が既にできていること。 Cloud DNS と SSL の準備 既に取得したドメインを Cloud DNS に登録するための、静的 IP を払い出す。 gcloud compute addresses create test-ip --global 作成した内容を確認するには下記コマンド。 gcloud compute addresses describe test-ip --global Cloud DNS のゾーン、レコードを作成。 2-1: Cloud DNS でゾーンを設定する。 内容については下記内容で追加。 DNS名: お名前.comで取得したドメイン 種類: 公開 DNSSEC: オン Cloud Logging: オフ 2-2: レコードの追加 A レコードで IPv4 アドレスを払い出しした静的 IP を設定して登録。(その他はデフォルト) 2-3: CAA レコードの追加 レコードで IPv4 に 0 issue "letsencrypt.org"を設定 2-4: 今回はお名前.com でドメインを取得したので、お名前.com 側でネームサーバーの設定を行うこと。 Cloud DNS の NS の値を設定。 証明書の発行 今回は Google マネージド SSL 証明書を利用して SSL 設定を行うため、下記コマンドで作成します。 gcloud compute ssl-certificates create test-ssl gcloud compute ssl-certificates list Kubernetes 側の設定 Cloud DNS の設定、証明書の発行を元に MultiClusterIngress の Annotations を下記に設定。 ingress.yaml metadata: name: backend-ingress annotations: networking.gke.io/static-ip: 取得した静的IP # example: "162.1111.111" networking.gke.io/pre-shared-certs: 取得したsslの名前 # 今回ならtest-ssl 最後に内容を適用します。 kubectl apply -f ingress.yaml ※ SSL の反映は時間がかかるため、数時間置いてから、確認してください。
アプリケーションとインフラを統合管理できるCrossPlaneを使ってみた
Cross Plane について Crossplane はオープン ソースの CNCF プロジェクトです。 Kubernetes API を使用して、任意のクラウド サービス プロバイダーでインフラストラクチャをプロビジョニング、構成、および使用できます。 CrossPlane を使うメリット GitOps ベースで管理できる。 アプリケーションとインフラストラクチャの構成を共存させることができ、CI/CD の複雑さを軽減できる。 minikube x CrossPlane を使って実際に GCP リソースを作成してみる。 minikube を起動させる。 minikube start minikube addons enable ingress CrossPlane のインストールを Helm 経由で行う。 kubectl create namespace crossplane-system helm repo add crossplane-stable https://charts.crossplane.io/stable helm repo update helm install crossplane --namespace crossplane-system crossplane-stable/crossplane ProviderConfig の設定を行う。 kubectl create secret generic gcp-creds -n crossplane-system --from-file=creds=./creds.json provider.ymal PROJECT_ID=my-project echo "apiVersion: gcp.crossplane.io/v1beta1 kind: ProviderConfig metadata: name: default spec: projectID: ${PROJECT_ID} credentials: source: Secret secretRef: namespace: crossplane-system name: gcp-creds key: creds" | kubectl apply -f - GCP の SA を作成する。 sa.yaml apiVersion: iam.gcp.crossplane.io/v1alpha1 kind: ServiceAccount metadata: name: perfect-test-sa spec: forProvider: displayName: "a beautiful service account test2" description: "perfection" deletionPolicy: Delete providerConfigRef: name: default リソースを作成する。 kubectl apply -f sa.yaml 今回はリソース単体を作成しただけですが、ArgoCD だったり、既存 terraform を組み込める provider を使うことでより移行コスト、効果を得られます。
Cloud Run Jobs, Workflows, Cloud Schedulerで手軽に始めるCronJob
Cloud Run Jobs について Cloud Run Jobs は Cloud Run 上でバッチ処理できる機能です。 Cloud Storage でのファイル処理、リクエストを処理しないコンテナなどに向いています。 また、今まで GCP 環境においてバッチ処理となると GKE の CronJob、GCE と選択肢が少ないため、気軽にバッチ処理環境を用意できる Cloud Run Jobs はその点においても強みです。 Cloud Run との機能の違いは下記ものがあります。 タスクタイムアウト最大 1 時間伸ばすことができる 明示的に並列処理を実行することができる 最大リトライ回数の設定ができる Cloud Run Jobs のデプロイ docker build -t asia.gcr.io/xxxx/xxxx . docker push asia.gcr.io/xxxx/xxxx gcloud beta run jobs create my-cloudrun-job --image=asia.gcr.io/xxxx/xxxx --set-env-vars=KEY1=VALUE1,KEY2=VALUE2 # envが必要な場合 Workflows のデプロイ Cloud Run Jobs の使用した Workflows の定義は下記のように行います。 main: steps: - my-cloudrun-job: call: googleapis.run.v1.namespaces.jobs.run args: name: "namespaces/project_id/jobs/my-cloudrun-job" location: asia-northeast1 - finish: return: "OK" ※複数の Cloud Run Jobs も設定可能です。 Workflows の定義が終わったら、デプロイを行います。 この時に指定するサービスアカウントの IAMRole に CloudRun の実行できる Role を追加してあることを確認してください。 実行権限ない場合、Workflows を実行しても 403 エラーで失敗してしまいます。 gcloud workflows deploy my-cloudrun-job-workflow --source=my-workflow.yml --location=asia-northeast1 --service-account=my-account@my-project.iam.gserviceaccount.com Cloud Scheduler の設定 gcloud scheduler jobs create http my-job --schedule="0 */3 * * *" --uri="https://workflowexecutions.googleapis.com/v1/projects/project_id/locations/asia-northeast1/workflows/my-cloudrun-job-workflow/executions" --http-method=POST こちらも実行するサービスアカウントに対して Workflows の実行権限があることを確認してください。 まとめ GKE と違いコマンド少し叩けばサラッとバッチをデプロイできる Cloud Run Jobs はとても便利すね。今後もさらに使い倒していきたいと思います！
ArgoCD Image UpdaterによるImageOpsの構築
ArgoCD Image Updater について Kubernetes 環境で GitOps として使用される ArgoCD Git リポジトリで管理されているマニフェスト(Helm chart など)の状態を監視してデプロイを行ってくれるのですが、コンテナのイメージまでは監視しません。 そこで役立つのが ArgoCD Image Updater です。 ArgoCD Image Updater は ArgoCD によって管理されている Kubernetes ワークロードのコンテナイメージを自動的に更新するツールです。 こちらを使用することにより、コンテナイメージの version 更新を自動化することができます。 ArgoCD Image Updater の設定 既に ArgoCD の設定を済ませていることを前提に進めます。ArgoCD の導入については過去の記事を参照。 また、ArgoCD 側の GitHub 連携も済ませるようにしてください。 ArgoCD Image Updater公式のインストール manifest を適用します。 そうすると ArgoCD Image Updater 関連の Pod が生成されるので、確認します。 無事確認ができたら、argocd の yml に anntations に設定を追加します。 # 例 annotations: argocd-image-updater.argoproj.io/image-list: username/image_name argocd-image-updater.argoproj.io/write-back-method: git argocd-image-updater.argoproj.io/write-back-target: kustomization argocd-image-updater.argoproj.io/git-branch: :image-updater-test 上記が完了したら、下記コマンドから Image upadte cycle の状況、status を確認してみましょう。 kubectl -n argocd logs --selector app.kubernetes.io/name=argocd-image-updater 実際にはこんな感じのログが出るかと思います。 level=info msg="Starting image update cycle, considering 1 annotated application(s) for update" level=info msg="Processing results: applications=1 images_considered=0 images_skipped=0 images_updated=0 errors=0" これで設定は完了です。あとは良しなに docker push してあげれば ArgoCD Image Updater が認識してくれて自動でイメージアップデートを行ってくれます。 詰まったこと ArgoCD Image Updater は ArgoCD の version が 2.x.x じゃないと上手く動かないようなので、2.x.x 以上にする。 log status が images_skipped の場合、annotations の記載に誤りがあると起きたりするのでタイポやミスがないか確認する。
肥大化したCIのymlの改善に使えるツール
CI の yml について CircleCI、GitLabCI を業務レベルの規模で使っているとある程度のボリュームになってしまい、可読性が落ちてしまいます。 その中で CIyml を改善できる方法を大きくふたつ見つけたので紹介します。 CircleCI config pack CircleCI 公式 Docs では下記のように紹介されています。 設定ファイルのパッケージ化 CLI の circleci config pack コマンド (上記の circleci orb pack とは異なる) を使用すると、複数のファイルをまとめて 1 つの YAML ファイルを作成できます。 pack コマンドには、ディレクトリ ツリー内の複数ファイルにまたがる YAML ドキュメントを解析する FYAML が実装されています。 これは、容量の大きな Orb のソース コードを分割している場合に特に利便性が高く、Orb の YAML 構成のカスタム編成を行うことができます。 circleci config pack は、ディレクトリ構造とファイルの内容に基づいて、ファイル システム ツリーを 1 つの YAML ファイルに変換します。 pack コマンドを使用するときのファイルの名前や編成に応じて、最終的にどのような orb.yml が出力されるかが決まります。 上記でも述べておりますが、ディレクトリ構造に基づいてとあるように一定の制約があります。 実際に分割する際は各層をフォルダ名として取り扱う必要があります。(commands,workflows,jobs など) その他デメリットとしてはアンカー、エイリアスを使用してる箇所については分割ができないという点です。*自分はこちらの理由で使用を断念しました。 なので、commands,workflows,jobs といった至る所でアンカー、エイリアスを使用してる場合は中途半端な分割管理になってしまうかと思います。 GitHub の方でも issue として切られています。 Support anchors and aliases across YAML files in decomposed orbs yq yq は YAML を操作できるコマンドラインツールで、特定キーワードから部分的に表示したり、差分、結合などなど行うことができるツールです。 こちらの場合、ディレクトリ構成の縛りもなくなりかつアンカー、エイリアスを使用してる箇所は そのまま貼り付ければ問題なく動作するので、いい感じにできます。 そして変更完了時はyq eaコマンドで分割した yml をマージして完成。 yq ea '. as $item ireduce ({}; . * $item )' path/to/*.yml まとめ 個人的には両方使ってみてどちらも良かったので、アンカー、エイリアス使ってるか、使ってないか次第だと思います。
Helmの基礎的な使い方:公開チャート編
はじめに 今回は CNCF プロジェクトに登録されているツール群を Kubernetes にインストールする、 よくありそうな使い方を備忘録として残します。 Helm について Helm は Kubernetes のパッケージマネージャーです。 CNCF では Graduated プロジェクトとして登録されています。 公開リポジトリの使用 前提として GKE でクラスター作成後としています。 使用したいリポジトリの検索 下記コマンドを使うことでチャート検索を行うことができます。 helm search repo argocd チャート一覧が確認できたら、チャートを選びましょう。 個人的な意見ですが、なるべく公式が提供してるチャートを選ぶようにしています。 公式かどうかわからない時はArtifactHUB検索ページより、 FILTERS:Official にして検索することで、公式の Chart が検索できるのでおすすめです。 ➜ helm search repo argocd NAME CHART VERSION APP VERSION DESCRIPTION argo/argocd-applicationset 1.6.0 v0.2.0 A Helm chart for installing ArgoCD ApplicationSet argo/argocd-image-updater 0.4.1 v0.10.3 A Helm chart for Argo CD Image Updater, a tool ... argo/argocd-notifications 1.5.2 v1.1.1 A Helm chart for ArgoCD notifications, an add-o... argo/argo-cd 3.26.9 v2.1.6 A Helm chart for ArgoCD, a declarative, GitOps ... Chart values ファイルの取得 values ファイルは Chart 内で使用されるパラメーターを編集するファイルで、ArgoCD の values ファイルの場合、 新規で追加するリポジトリのパラメーター、Credentials、Applications などをコードベースで落とし込むことができます。 helm inspect values argo/argo-cd > argo-values.yaml ※今回はデフォルト値のまま install を行いますが、カスタマイズしたい場合は各 Helm チャートの Documentaion を確認することで、 効率よく設定できます。今回の ArgoCD であればこちら インストール 最後に values ファイルを適用してインストールを行います。 helm install --name-template argocd --namespace argocd -f argocd-values.yaml argo/argo-cd インストールが完了したら、実際にインストールできてるか確認してみましょう。 関連 pod が作成されてると思います。 kubectl get pods -n argocd values ファイルの update helm upgrade -f --name-template argocd --namespace argocd -f argocd-values.yaml argo/argo-cd アプリケーションの uninstall helm uninstall argocd -n argocd
ArgoCD触ってみた
ArgoCD について ArgoCD は Kubernetes のための宣言型の GitOpsCD ツールです。 上記で GitOps と述べてる通り、ArgoCD は Git リポジトリで管理されているマニフェスト(Helm chart など)の状態を監視して デプロイを行います。 ArgoCD の構築 GKE でクラスター構築後に namespace と ArgoCD の install yml を apply します。 ※GKE クラスター machine-type は g2-small でも大丈夫です。 kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml インストール後に外部 IP アクセスの公開設定を行います。 kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}' ここで ArgoCD の画面にアクセスできるか確認しましょう。 GKE であれば、「Kubernetes Engine」→「Services と Ingress」から argocd-server のエンドポイントを確認できるので、そちらをクリック。 CLI であれば、service の EXTERNAL_IP を確認。 kubectl get svc -n argocd ブラウザからアクセスして管理画面が確認できたら、実際にログインしてみましょう。 初期アカウントの情報は下記になります。 username: admin password: 下記コマンドを叩いて表示された値 kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ログインできない場合、パスワードを初期化してください。 kubectl patch secret argocd-secret -p '{"data": {"admin.password": null, "admin.passwordMtime": null}}' 次に ArgoCD に Git リポジトリの登録を行います。 私の場合プライベートリポジトリでの登録を行いため、argocd repo add から登録したいと思います。 パブリックリポジトリであれば、歯車マークを選択し、「Repositories」⇨「CONNECT REPO USING HTTPS」から追加できます。 下記コマンドを叩いてリポジトリ登録を行います。 argocd login --insecure localhost:8080 argocd repo add git@github.com:${USER}/${REPOSITORY_NAME}.git --ssh-private-key-path ~/.ssh/${PRIVKEY_KEY} 次にアプリ作成を行います。 「NEW APP」から名前は任意で、「SOURCE」の「Repository URL」を追加したリポジトリに設定(manifest のリポジトリ) 「Revision」は監視対象のブランチ今回は master ブランチ 「Namespace」は default 今回マニフェストファイルを Helm で管理していたので、Helm の「VALUES FILES」を該当のファイルに設定。 これで「CREATE」を押すとアプリが作成されます。 最後にアプリページから「SYNC」→「SYNCHRONIZE」ボタンを押すとデプロイが開始され、アプリケーションが GKE に展開します。 この後は「アプリケーションのファイル更新」⇨「イメージリポジトリの更新」⇨「ArgoCD の監視対象の manifest 更新(image tag) 」⇨「ArgoCD が Sync」という流れになります。 これで GitOps を用いた CD 基盤を構築することができました。
気になってたGitOpsについて
GitOps について GitOps は Weaveworks 社が提唱する開発者支援ツールを使用して運用する手法。 GitOps を使用することでインフラ、アプリケーション全体を Git ベースで管理して Kubernetes にデプロイすることができる。 ※ GitOps について Kubernetes が前提することが多く書かれていますが、GitLab 社の説明によると、必須ではないようです。 メリット とにかく Git ベースで Kubernetes にデプロイできるので、Kubernetes の知識があまりなくても 開発者はアプリケーション開発に専念できるのがいい。(デプロイに手間取らない) Kubernetes での開発に慣れてないなら、なお取り入れた方がいいのかなと感じました。とにかく簡単に最新のアプリケーションの状態に更新できた。 GitOps において CI/CD ツールが不可欠なのだが、Argo CD, Jenkins X などを使うことによって GUI ベースでアプリケーションの状態、デプロイ状況を確認できる。 CD ツールにもよると思いますが、定期的に Git リポジトリの状態を監視して差分があれば同期してくれる。 などなど、いろんなメリットありました。 次回は自分が使用した Argo CD の困ったこと、設定の流れとか備忘録程度に書いていきたいと思います。
Terraform x GKEでuse_ip_aliasesが使えなくなってた
Native Cluster のの有効で使われる、use_ip_aliases が使えなくなってる。 下記内容で terraform plan などを行ってしまうとAn argument named "use_ip_aliases" is not expected here.が起きてしまう。 resource "google_container_cluster" "primary" { ip_allocation_policy { use_ip_aliases = true } } 解決策 Google Provier 3.0.0 のアップグレードで use_ip_aliases の bool 値での制御がなくなった。 下記形で空のブロックを残す形でいいようです。false 時は ip_allocation_policy 自体を削除する。 ip_allocation_policy {}
GKExRailsをやってみた時のnote
Cloud Shell は gcloud コマンドを使えばダッシュボードに行かなくても見れる。 初めて GKE 使い始めてからずっと Cloud Shell 経由で kubectl してたのですが、こちら gcloud を使えば ターミナルで kubectl 操作が出来ました。あるだろうなーっとは思っていて、調べずにいたのですが やはりこちらの方がいいですね。 Docker のように pod 内コンテナリソースへアクセスが出来ることを忘れてた kubectl exec exec -it pod-name bash GKE に rails を乗せる時の migrate は Job で行うこともできる デプロイ後に必要なrails db:migrateは Job で管理するのもあり、 ただし成功時の pod 削除時のスクリプトも必要になるため、kubectl exec経由で migrate を かけるパターンもあるようです。どっちがベストプラクティスなんだろう。。 Enviroment は Secret で管理 kubectl create generic app-secrets --from-literal=ACCESS_TOKEN=value edit から呼び出してstringDataで値をセットしてファイル保存するだけでよしなにやってくれて便利 kubectl edit secret app-secrets
Kubernetesで50Xエラー出た時の確認ポイント
適用した pod の確認 kubectl get pods 適用した pod の STATUS が Running になってるのか見る describe で port がリッスンしてるのか確認 kubectl describe pod pod-id service が正常であるかの確認 kubectl get svc NodePort であれば 80:xxxxx の形になっているかの確認 ingress が正常に起動してるかの確認 kubectl get ing apply 時に ADDRESS が割り振られるまで時間がかかるので、しばらく待つ log の確認 kubectl log pod-id
Dangerfileでファイルリストをmarkdown形式で表示するとき
Dangerfile の markdown の使い方に関して基本的なことしか残ってなかったので その時のメモ ソースコード markdown(<<~MARKDOWN) ## Add files * #{git.add_files.map { |path| "`#{path}`" }.join("\n* ")} MARKDOWN
SinatraをKubernetesで動かしてみた時の備忘録
初めて Sinatra アプリケーションを Kubernetes で動かしてみた時のメモです。 Deployment Deployment を使用することで簡単に ReplicaSet のバージョンを管理することが出来る。 --recordで操作履歴をつけれる。 Service Pod にアクセスするためのポリシー定義をする場所。 Service がないと外部に公開されない。 Service type は 4 つある。 ClusterIP NodePort LoadBalancer ExternalName Ingress 外部からのアクセスを管理するオブジェクト。 ホストごとにサービス切り替えたり出来る。 最後に 上記をもとに作成したのがこちらsinatra-kube 実際に手動かしながらの方が理解しやすかったので、もっと早くさわればよかった。
GKEをなるべく安くする時にしたこと
個人学習レベルであれば、無料試用の 300 クレジットアカウント用意して使えば良いだけですが それを用意するのもめんどくさい人なので、自分が安く使うときにしたことを書く。 machine-type を小さいものにする gcloud cluster create 時に option でmachine-typeを micro にすることによってコストを削減できる。 ただし、現在だと micro では最低限の動作環境に満たないため small にするのが良さそう。実際私も small にした。 Node 数を削減する デフォルトで作成される node 数:3 を 1 にgcloud container clusters resizeで変更を行う。 とりあえず、DB も使わないアプリケーションをさっと動かしたい時に使うといい。 Google Container Registry を gcr ではなく asia.gcr に設定する pull する場所に近いロケーションをしないと無駄にコストが発生してしまう。 Cloud Run の時に gcr にして確かに料金が発生した覚えがある。。 番外:IBM Cloud Kubernetes Service の無料プランを使う GKE にこだわりがなければ、 IBM の Kubernetes だと従量課金アカウントを用意してさえいれば、Cluster 作成時に無料プランが用意されてるので、料金気にせずに済む。
遅かったCircleCIを改善する時に見たところ
私が前職で所属してた会社ではバックエンドに Rails を使用してるプロジェクトだったのですが、PR を作成毎に起動する CircleCI がとても遅い問題を抱えておりました。 大体 1h~2h これでは、通常の開発どころか緊急対応の際にも大きく影響してしまいます。 それで、これをどうにか出来ないかと思い直した時の備忘録です。 パフォーマンス調査 CI のテスト部分のパフォーマンス解析にはtest-profを使用。 これを使うことによって spec 内で無駄にレコードが生成されていないかを確認する。 その他にも、便利メソッドが使えたり、aggregate_failures に関する調査をすることができる。 ちなみに実際にパフォーマンス調査をして数百レコード単位で無駄なレコードが生成されていることがわかった。 CircleCI の parallelism 化 config.yml 内に parallelism の項目を指定することでテスト並列実行することができる。 言語に依存しないのが良いところ。 自分の場合はさらにタイミングデータを用いて並列の最適化を行いました。 ビルドイメージの最適化 最後は細かい部分になるが、CI で使うビルドイメージを CircleCI 側で提供されているものに変更する。こちらはベストプラクティスとしても紹介されている。