先週の土曜日、JAZUG札幌支部（きたあず）第14回勉強会に参加して、Azure Container Service の話をしてきました。
セッションの内容としては、最初の一歩を踏み出すための基礎知識やハマりどころなどを、デモを交えて説明しました。
ちょっと試してみるには少し難しく敷居が高いので、Kubernetes 周りのツールも含め、Azure Container Service 自体も使いやすくなっていくことを期待したいです。
今回、東京以外の勉強会には初めて参加しました。
興味のあるテクノロジーを勉強しようと思ったとき、インターネットや書籍からも情報を収集できますが、そのテクノロジーを使ったことがある人の話を聞くのがよいと思います。特にアップデートの早いクラウド周りは。
東京に比べたら、そのような機会は少ないと思うので、何か１つでも学んでもらって、自分でも試してみようと思えるきっかけを提供できたとしたら幸いです。
勉強会の参加者や運営メンバーとも交流することができ、楽しい時間を過ごすことができました。また機会があれば、きたあずに参加したいです。
前回の記事では、Azure Container Service に Kubernetes を展開し、YAML ファイルを使ってデプロイしました。
gooner.hateblo.jp
コンテナ内のディスク上のデータは一時的なものであり、コンテナが再起動されると、データは失われます。データを永続化することで、コンテナが再起動されてもデータが失われなくなり、コンテナ間でデータを共有することも可能になります。
今回は、Azure Files と Azure Data Disks にボリュームをマウントしてみます。
コンテナ内のディスク上のディレクトリを外部ストレージにマウントさせることで、データを永続化させることができます。
Kubernetes では、GCE や AWS などのクラウドプラットフォームのストレージ、NFS のようなネットワークストレージをサポートしています。
kubernetes.io
MySQL の Docker Image をデプロイして、Azure Files にマウントします。
まず、Azure Storage に接続するために、アカウント名とキーを定義した Secret を作成します。
apiVersion: v1 kind: Secret metadata: name: azure-secret type: Opaque data: azurestorageaccountname: ajczeGVidG5ncnpmcW1zdHIw azurestorageaccountkey: SHlZTFp0aENwYTRzeXprcmcwZUJES0s0eTRRekJQem1RVFJOdCtYSnhhajd6eFVMaUMvRUZUS0c4SDFCbEpZSzBUL21LZ1FGcDc1NmFtZUpLekNnYWc9PQ==
アカウント名とキーに設定する値は、Base64 エンコードする必要があります。
次に、MySQL の Deployment を定義します。
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mysql-deployment spec: replicas: 1 template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD value: Pa$$w0rd ports: - containerPort: 3306 volumeMounts: - name: azure mountPath: /var/lib/mysql volumes: - name: azure azureFile: secretName: azure-secret shareName: mysql-volumes readOnly: false
コンテナ内のディレクトリ（/var/lib/mysql）を、Azure Files の mysql-volumes にマウントしています。mysql-volumes は、事前に Azure Portal から作成しておきます。
上記の２つの YAML ファイルをデプロイすると、Azure Files にボリュームマウントされた MySQL の Pod が作成されます。
$ kubectl create -f azure-secret.yaml secret "azure-secret" created $ kubectl create -f mysql-deployment.yaml deployment "mysql-deployment" created $ kubectl get secret NAME TYPE DATA AGE azure-secret Opaque 2 3m default-token-17f2z kubernetes.io/service-account-token 3 17m $ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mysql-deployment 1 1 1 1 32s
Azure Portal で確認すると、MySQL のディレクトリがマウントされていることが分かります。
PostgreSQL の Docker Image をデプロイして、Persistent Volumes で Azure Data Disks にマウントします。
まず、Data Disks のサイズやアクセスモードを指定するために、Persistent Volume Claims を作成します。
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: postgres-pv-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 3Gi
次に、PostgreSQL の Deployment を定義します。
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: postgres-deployment spec: replicas: 1 template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres env: - name: POSTGRES_PASSWORD value: Pa$$w0rd - name: PGDATA value: /var/lib/postgresql/data/pgdata ports: - containerPort: 5432 volumeMounts: - name: data mountPath: /var/lib/postgresql/data/pgdata subPath: postgresdata volumes: - name: data persistentVolumeClaim: claimName: postgres-pv-claim
コンテナ内のディレクトリ（/var/lib/postgresql/data/pgdata）を、Persistent Volume Claims にマウントしています。
上記の２つの YAML ファイルをデプロイすると、Azure Data Disks にボリュームマウントされた PostgreSQL の Pod が作成されます。
$ kubectl create -f postgres-pv-claim.yaml persistentvolumeclaim "postgres-pv-claim" created $ kubectl create -f postgres-deployment.yaml deployment "postgres-deployment" created $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE postgres-pv-claim Bound pvc-2fbe3042-4522-11e7-8dae-000d3a12075c 3Gi RWO 27s kubectl get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-2fbe3042-4522-11e7-8dae-000d3a12075c 3Gi RWO Delete Bound default/postgres-pv-claim 1m kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE postgres-deployment 1 1 1 1 2m
Persistent Volume Claims が作成され、それにバインドされた Persistent Volume も同時に作成されたことが分かります。
Azure Portal で確認すると、Data Disks が追加されていることが分かります。
なお、Azure Data Disks の設定を明示的に行っていませんが、これは Azure Container Service がデフォルトの StorageClass を用意してくれているためです。
$ kubectl describe storageclass default Name: default IsDefaultClass: Yes Annotations: kubectl.kubernetes.io/last-applied-configuration={"kind":"StorageClass","apiVersion":"storage.k8s.io/v1beta1","metadata":{"name":"default","creationTimestamp":null,"labels":{"kubernetes.io/cluster-service":"true"},"annotations":{"storageclass.beta.kubernetes.io/is-default-class":"true"}},"provisioner":"kubernetes.io/azure-disk"},storageclass.beta.kubernetes.io/is-default-class=true Provisioner: kubernetes.io/azure-disk Parameters: <none> No events.
自分で Persistent Volume や StorageClass を定義することで、Azure Data Disks 以外のストレージにマウントさせることも可能です。
今回は、Azure Files と Azure Data Disks にボリュームをマウントしてみました。
コンテナは揮発性をもつ環境のため、ステートフルなアプリケーションをデプロイする際には、データを永続化する必要があります。
Azure のストレージに直接マウントすることでもできますし、Persistent Volumes を使うことで、クラウドプラットフォームへの依存度を下げることもできます。
先週の土曜日、Global Azure Bootcamp 2017 に参加して LT してきました。
２週間ぐらい前に Microsoft が Deis を買収した発表があったので、Helm の話をしました。Helm は、Kubernetes のパッケージマネージャーなので、install コマンドでサクッとデプロイできます。YAML をゴリゴリ書くのは大変なので、Charts Repository を参考にするのもありです。今後、Kubernetes を便利に使えるようになっていくことに期待したいです。
本編としては、Azure 最新情報のまとめは、JAZUG 女子部のお二人による掛け合いが流石でした。スライドもゆるまとめと言いつつも、とても分かりやすい内容です。
bitFlyer さんによる障害復旧の話は、大変興味深かったです。一部のサービスに障害が発生しても、顧客にサービスを提供し続けられるアーキテクチャは重要です。
DocumentDB の話は、タイトル通り DeepDive でした。PaaS で提供される NoSQL でポテンシャルの高いサービスなので、プロダクション環境で使ってみたいところです。
そういえば、アンケートを作り忘れました。多くの方にご参加頂けたので、感想や今後のリクエストなどを聞いてみたかったです。今回初めて参加された方も多い印象でした。何かあれば、お気軽に Facebook の JAZUG グループや Twitter の #jazug までお願いします。
