Kubernetes

こんな感じでNextCloudをk8sにデプロイするとします。 nextcloud.yaml 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 apiVersion: apps/v1 kind: Deployment metadata: name: nextcloud namespace: default spec: replicas: 1 selector: matchLabels: app: nextcloud template: metadata: labels: app: nextcloud spec: containers: - name: nextcloud image: nextcloud env: - name: NEXTCLOUD_DATA_DIR value: /data ports: - containerPort: 80 protocol: TCP volumeMounts: - name: myvolume subPath: config mountPath: /var/www/html - name: myvolume subPath: data mountPath: /data volumes: - name: myvolume persistentVolumeClaim: claimName: myvolume securityContext: fsGroup: 33 --- apiVersion: v1 kind: Service metadata: name: nextcloud namespace: default spec: ports: - name: http port: 80 protocol: TCP selector: app: nextcloud clusterIP: None すると初回ログイン後に以下のようなエラーが出てきます。...

2021年6月1日からGoogle Photoの容量が無制限ではなくなり、無料枠は15GBに制限されてしまいました。 完全に音楽サーバーを構築した話の二番煎じですが、自宅k8sに写真サーバーを構築してそちらに移行する事にしました。 デプロイ self-hostedな写真サーバーで最もメジャーなプロダクトはPiwigoの模様。 サクっとyamlを書いてデプロイします。 deployment.yaml 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 apiVersion: apps/v1 kind: Deployment metadata: name: piwigo spec: replicas: 1 selector: matchLabels: app: piwigo template: metadata: labels: app: piwigo spec: containers: - name: piwigo image: lscr....

神(Google)は「Play Music」と言われた。するとGoogle Play Musicがあった。 神はそのUXを見て、良しとされた。 神はまた言われた。「YouTube Musicに移行してください」 UIは使いづらく、バックグラウンド再生できず、ロードは遅くなり、楽曲メタデータは編集できなくなった。 神はお休みになった。 概要 所有している音楽データをアップロードし、インターネット経由で聴くというサービスでしっくりくるものがないため、自宅Kubernetesクラスタに自前で構築してみます。 家庭内LANからファイルサーバーとして使える ファイルサーバーにアップロードした音楽データをインターネット経由で聴ける ファイルサイズが大きい楽曲はサーバーサイドでリアルタイムに圧縮して配信する という要件から、以下のような構成にしてみます。 音楽配信サーバーには Airsonicを使います Ingress(L7ロードバランサー)経由でインターネットに接続します IngressをTLS終端にします ファイルサーバーとしてSambaを構築します Airsonicとストレージを共有します LoadBalancer Service(L4ロードバランサー)経由で家庭内LANに接続し、インターネットからは遮断します 構築 1. Storage まず初めに、Podからホストマシンのストレージを使うためのPersistentVolume(PV)とPersistentVolumeClaim(PVC)を作成します。 今回は node1 の /mnt/hdd に音楽データとメタデータ(設定、アカウント情報など)を永続化するとします。 pv.yaml 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 apiVersion: v1 kind: PersistentVolume metadata: name: music spec: capacity: storage: 1000Gi accessModes: - ReadWriteOnce local: path: /mnt/hdd/music nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes....

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....

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

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

git branchに変更が加わった際、 JUnit test (with MySQL) docker build Kubernetes環境にデプロイ (CIOps) が行われるJavaプロジェクトを構築します。 本番運用ではArgoCDなどgitOps構築をお勧めします 登場するもの OSS Maven MySQL Docker サービス GitHub CircleCI AWS (ECR, EKS) ⇦ 微修正でその他マネージドk8sにも応用可能かと思います。 サンプルプロジェクトの実装 最終的にディレクトリ構成はこんな感じになります。順を追って作っていきます。 GitHubからcloneして頂いても結構です。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 testproject/ ├ src/ │ ├ main/ │ │ └ java/ │ │ └testpackage/ │ │ └Main.java │ └ test/ │ └ java/ │ └testpackage/ │ └MainTest.java ├ ....

Javaプロセスを一定時間毎にチェックし、ハングしていればPodを再起動する仕組みの備忘録です。 Kubernetes LivenessProbeに関する詳細はこちらをご参照ください。 Java実装 監視対象クラス テスト用に、インスタンスが生成されてから10秒後に isAlive() == falseになるように実装します。 1 2 3 4 5 6 7 8 9 10 public class SomeResource { final long createdTime; public SomeResource() { this.createdTime = System.currentTimeMillis(); } public boolean isAlive() { return System.currentTimeMillis() - createdTime < 10000; } } 監視用エンドポイント SomeResource#isAlive() == trueの時はレスポンスコード 200, falseの時は 500を返すように実装します。 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 import com....