KubernetesでGitOps運用となると必ず話題になるのがSecretの管理です。 Sealed Secretsやkubesecなどの手元で暗号化する系 Kubernetes Secrets Store CSI Driverやkubernetes-external-secretsなどの外部シークレットストアから引っ張ってくる系 機密情報だけ別Repoにする など様々な方法がありますが、学習コストや実運用をイメージするとどのソリューションもしっくり来ませんでした。 そんな中でIBM社が開発しているArgoCD Vault Pluginを触ってみたところ、ArgoCDのデプロイ時にplaceholderをreplaceするという合理的かつシンプルな仕組みで非常に好感触でした。 2022/02追記: Argo Projectに移管されたようです。 https://argocd-vault-plugin.readthedocs.io/en/stable/ (上記でいう「外部シークレットストアから引っ張ってくる系」の一種に該当します) ArgoCD Vault Plugin (以下AVP) は日本語の情報が皆無に等しかったため、布教の目的も込めて導入・運用方法を記載します。 テスト AVPはbrewからも導入でき、手元で簡単にテストができます。 シークレットストアはAWS Secrets Mangerを使う前提で解説します。 ローカル環境にインストール (Mac) 1 $ brew install argocd-vault-plugin AWS Secrets Mangerに機密文字列を登録する 1 2 key: my_secret value: foobar Kubernetes Manifestを作成する Secretの実装は非常に簡単で、 アノテーションに参照するSecret Managerのパスを記述する Secret Managerのキー名を<> で囲う だけでOKです。 1 2 3 4 5 6 7 8 apiVersion: v1 kind: Secret metadata: name: credentials annotations: avp.kubernetes.io/path: "avp/test" data: MY_SECRET: <my_secret | base64encode> Decryptのテスト 1 2 3 4 5 6 7 8 9 10 11 12 13 $ export AWS_ACCESS_KEY_ID=xxxx $ export AWS_SECRET_ACCESS_KEY=xxxx $ export AWS_REGION=ap-northeast-1 $ export AVP_TYPE=awssecretsmanager $ argocd-vault-plugin generate path/to/secrets....

Argo workflowsでは Default Workflow Spec を設定する事でワークフローに色々とパッチできる。 以下のようにexit-handlerをworkflowDefaultsにしておくと、ワークフロー側に何も記述せずとも失敗時にSlackに通知できる。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 apiVersion: v1 kind: ConfigMap metadata: name: workflow-controller-configmap data: workflowDefaults: | spec: onExit: exit-handler templates: - name: exit-handler when: "{{workflow.status}} != Succeeded" container: image: curlimages/curl:latest args: ["-X","POST","-H",'Content-type: application/json',"--data", '{"attachments": [{"title":"Workflow status: {{workflow.status}}","color": "danger","fields": [{"title": "name", "value": "{{workflow.name}}", "short": true }, {"title": "url", "value": "https://{{inputs....

Argo Workflowsの公式ドキュメントが分かりづらかったので、試しにembulkを実行するテンプレートを作ってみました。 config.ymlはartifactsとして渡します。 Dockerfile 1 2 3 4 5 6 7 8 9 10 11 12 FROM openjdk:8-jre-alpine ARG VERSION=latest RUN mkdir -p /root/.embulk/bin \ && wget -q https://dl.embulk.org/embulk-${VERSION}.jar -O /root/.embulk/bin/embulk \ && chmod +x /root/.embulk/bin/embulk ENV PATH=$PATH:/root/.embulk/bin RUN apk add --no-cache libc6-compat RUN embulk gem install embulk-input-s3 ENTRYPOINT ["java", "-jar", "/root/.embulk/bin/embulk"] 1 2 3 $ EMBULK_VERSION=0.9.23 $ docker build . -t embulk:$EMBULK_VERSION --build-arg VERSION=$EMBULK_VERSION $ docker run -v /path/to/configfile:/config embulk:latest run /config/config....

S3にアップロードされたファイルをfluentdでBigQueryにinsertする際、S3キー名に応じてテーブルを振り分けるサンプルを掲載します。 ここではフォーマットはs3://my-bucket/{BigQueryデータセット名}/{テーブル名}/{uuid}.csv.gz とします。 fluent.conf 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 <source> tag s3 @type s3 s3_bucket my-bucket s3_region ap-northeast-1 <sqs> queue_name my-queue </sqs> </source> <match s3> @type rewrite_tag_filter <rule> key s3_key pattern ^(....

kubectl logsはPID1の標準出力を表示するため、直接書き込んでしまえばなんでも表示できる。 1 2 3 $ kubectl exec -it pod-xxx bash # echo 'show as stdin' > /proc/1/fd/1 # echo 'show as stderr' > /proc/1/fd/2 1 2 3 4 $ kubectl logs pod-xxx show as stdin show as stderr

公式ドキュメントの Sharing Git credentials with your containerに色々と記載があるが、非常に簡単なソリューションがあったためメモ Mac 1 2 3 4 5 $ sudo vi ~/.ssh/config Host github.com AddKeysToAgent yes UseKeychain yes Windows 1 2 3 > Set-Service ssh-agent -StartupType Automatic > Start-Service ssh-agent > ssh-add $HOME/.ssh/id_rsa WSL2 1 sudo apt install keychain ~/.bashrc 1 2 keychain -q --nogui $HOME/.ssh/id_rsa source $HOME/.keychain/$(hostname)-sh

標準的な配列の分割キーボードをようやく見つけたためAliExpressで購入。 PCBは予めソケット化されており、差し込むだけで完成なので組み立て手順は割愛。 HHKB liteっぽくキーマップを実装。 左スペースキー横は日英切り替え(`Alt + ``)にしてみる。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 #include QMK_KEYBOARD_H enum layer_names { BASE, // default layer _FN, // function layer }; enum custom_keycodes { M_KANA = SAFE_RANGE, }; bool process_record_user(uint16_t keycode, keyrecord_t *record) { if (record->event....

Apache AirflowにおいてOperator間で値を渡すにはXCOMを使用しますが、 Airflow macroで文字列として取得する PythonOperatorでtask_instanceから取得する の2通りの方法があります。 しかし、例えば GoogleCloudStorageListOperatorでファイルのリストを取得 » GoogleCloudStorageToBigQueryOperator でリストされたファイルをBigQueryにロードする といったことをやりたい場合、XCOMからファイルのリストを配列として取得しコンストラクタに渡さなければならないためすこし工夫が必要になります。 本稿ではその実装について記載します。 NG 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ... list_files = GoogleCloudStorageListOperator( task_id='list_files', bucket='my_bucket', prefix='path/to/file/', xcom_push=True, dag=dag ) gcs_to_bigquery = GoogleCloudStorageToBigQueryOperator( task_id='gcs_to_bigquery', bucket='my_bucket', source_objects="{{ ti.xcom_pull(task_ids='list_files') }}", destination_project_dataset_table='project:dataset.table', autodetect=True, dag=dag ) list_files >> gcs_to_bigquery ... ファイル名の配列がデシリアライズされた状態で source_objects に渡されてしまうため動作しません。 OK 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 ....

1 kubectl create job 作成するJob名 --from=cronjob/CronJob名 https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-job-em-

terraformに対応していないクラウドリソースを local-exec を用いてterraform化してみます。 今回はBigQueryのユーザー定義関数(UDF)でやってみます。 実装 さて早速。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 variable project{} resource "null_resource" "bigquery-udf" { <- #1 triggers = { query = "CREATE OR REPLACE FUNCTION my_dataset.TEST_FUNCTION(x INT64) AS (x + 1);" <- #2 } provisioner "local-exec" { <- #3 interpreter = ["bq", "query", "--use_legacy_sql=false", "--project_id=${var.project}"] <- #4 command = self.triggers.query on_failure = fail <- #5 } provisioner "local-exec" { when = destroy <- #6 interpreter = ["bq", "query", "--use_legacy_sql=false", "--project_id=${var....