Google Cloudのlinuxとローカルlinuxで、それぞれmariadbとdjangoのコンテナ動かしてる。
ローカルlinuxでdjangoの開発しといて、Google Cloudで本利用し、mariadbの永続化領域(pv)をGoogleDrive経由でtar.gzファイルをローカルlinuxに持ってきてる。
これをmacで動かしはじめたminikubeでも構成作れるかやってみる。
kubectlのコマンドライン練習と、マニフェスト作成の練習ね。
目標
前回はmacにminikube入れてhyperkitの中で動くコンテナをPodに見立てて、xrdpできるPodが常時稼働できるようにした。
今回も最初に目標設定。
イメージ湧かせましょ。
右端のGoogleからローカルlinuxへのコピーこんな感じ。
GCE ubuntu22のxrdpコンテナは、ローカルlinuxにssh経由のポートフォワードさせて、httpsひっかけたDjangoコンテナを使ってる。
Djangoは8080ポートで公開して、それをhttpsで拾わせて30443で公開しxrdpコンテナにローカル端末からrdpしてブラウザ経由で利用。
mariadbの永続化領域がpvにあるから、それをときどきlocal ubuntu22にtar.gzにしてvmdkに持ってくる。
local ubuntu22のxrdpコンテナは、ローカルやから普通にrdp開くし、djangoの開発とかモジュール更新もほぼここで維持。
dockerイメージはここで管理しておいて、mac向けにdocker saveするからmacではそれをdocker loadする。
mac(gvis-mac.intra.gavann-it.com)ではdocker buildせずdocker loadしてイメージを維持し、local ubuntu22のvmdkに置いてあるmariadbの永続化領域をhyperkitの/dataにコピーさせて使う。
hyperkitの/dataへはminikube sshしてwindows側からteraterm経由でコピーするか、--mount-string /Users/nari/Documents/personal/minikube/:/minikubeMacってminikube起動時に指定してマウントポイントを経由してmacからコピーする。
+-mac(gvis-mac)----------------+ | +-minikube-------+ | | | | | | +----------------+ | | +-hyperkit-----------------+ | | | +-container-+ | | | | | kubernetes| | | +-local ubuntu22 linux--------+ +-GCE ubuntu22 linux----------+ | | +-----------+ +-/data-+ | | | +-docker---------+ +-vmdk-+ | | +-docker---------+ +--pv--+ | | | +-container-+ | | | | | | +-container-+ | | data | | | | +-container-+ | | data | | | | | *Django | | *d1 | | | | | | Django | | | d1 | | | | | Django | | | d1 | | | | +-----------+ +-------+ | | | | +-----------+ | +------+ | | | +-----------+ | +------+ | | | +-container-+ | | | | | | +-container-+ | | | | | | +-container-+ | | | | | | | *mariadb | | *d2 | | | | | | mariadb | | | d2 | | | | | mariadb | | | d2 | | | | +-----------+ +-------+ | | | | +-----------+ | +------+ | | | +-----------+ | +------+ | | | +-container-+ | | | | | | +-container-+ | | | | | | +-container-+ | | | | | | | xrdp-ubu22| | d3 | | | <- | | | xrdp-ubu22| | | d3 | | <- | | | xrdp-ubu22| | | d3 | | | | +-----------+ +-------+ | | <- | | +-----------+ | +------+ | <- | | +-----------+ | +------+ | | | | | <- | | | | <- | | +-container-+ | | | | +-------+ | | | | | | | | | gitlab | | | | | | mini | | | | | | | | | +-----------+ | | | | +-container-+ | kube | | | | | +-container-+ | | | | +-container-+ | | | | | *https | | Mac | | | | | | https | | | | | | https | | | | | +-----------+ +-------+ | | | | +-----------+ | | | | +-----------+ | | | +--------------------------+ | | +----------------+ | | +----------------+ | +------------------------------+ +-----------------------------+ +-----------------------------+
今回は「*」のついたところを作って、kubernetesのサービスのマニフェストも用意した。
- *mariadb 3306 ->13306
- *Django 8080 ->38080
- *https 80,443->30080,30443
- *d1 Django用永続化領域 1GiB
- *d2 mariadb用永続化領域 20GiB
mariadbは13306ポートで参照。
ちょっとややこしいけど、Djangoは8080->38080で公開してhttpsのコンテナに拾わせておいて、httpsからは443->30443で公開。
38080はPod間通信ではつながるけど、mac以外のホストからは30443でブラウザ参照。
docker-composeをlinux側で作って動かしてるので、それをkubernetesに置き換えるっていう感じで考えた。
docker-compose.ymlの定義
local ubuntu22 linuxの中で使ってるdocker-compose.ymlの定義はこんな感じ。
version: "3"
services:
sv_mariadb1011:
hostname: svmariadb1011
build:
context: ./nariDockerDat/sv_mariadb11/
dockerfile: sv_mariadb11_Dockerfile
image: mariadb:1011
ports:
- "13306:3306"
env_file:
- ./nariDockerDat/sv_mariadb11/env_sv_mariadb11.txt
volumes:
- ./nariDockerDat/sv_mariadb11/data:/var/lib/mysql
- ./nariDockerDat/sv_mariadb11conf:/etc/mysql/conf.d
### 【参考】
### https://sleepless-se.net/2018/06/12/dockerdjangoを無料でhttps化して簡単にデプロイする方法/
### https://github.com/SteveLTN/https-portal
###
### ※注意
### /var/lib/nginx-conf/にあるdefault*.erbファイルに
###「client_max_body_size 30M; ## for gvisapp」を追記して
### アプリケーションからのblob保存で「413 Request Entity Too Large」が
### 出ないようにすること
###
sv_https-portal:
image: steveltn/https-portal:1
ports:
- "30080:80"
- "30443:443"
environment:
DOMAINS: 'nafslinux.intra.gavann-it.com -> http://svdjango:8080'
STAGE: 'local' # or 'production'
volumes:
- ./nariDockerDat/sv_django-ssl_certs:/var/lib/https-portal
sv_django:
image: sv_django:4
build: ./nariDockerDat/sv_django-uwsgi-nginx
hostname: svdjango
volumes:
- ./nariDockerDat/sv_django-uwsgi-nginx/app:/code/app
ports:
- "38080:8080"
最初はkomposeってツールがあって、それを使ってみた。
brewで一発で入るし、マニフェストを書くのはどうしたらいいのかわかってなくてdocker-compose.ymlを流用したいときには助けてはくれる。
それぞれdeploymentのマニフェストがサービスのマニフェストと、pvc/pvを使う感じの出力をしてくれる。
ENVとかdocker-compose.ymlに書いてるから、configmapの定義作ってくれたのはそのまま使わせてもらった。
ただし、deploymentには不要な記述が多かったから、参考にはしたけど自分で解釈しながら作り直した。
結局komposeはもう使ってない。
名前引き
単一ホスト利用なら、普通だったら/etc/hostsとかC:\Windows\System32\drivers\etcに書けばいい。
自分の場合はルータのDNS機能使ってるので、そこに登録してる。
macから名前引き確認してみる。
nari@gvis-mac ~ % nslookup gvis-mac.intra.gavann-it.com Server: 172.16.17.15 Address: 172.16.17.15#53 Name: gvis-mac.intra.gavann-it.com Address: 192.168.1.117 nari@gvis-mac ~ %
この登録した名前で、作ったPodのポート番号をwindowsホストとかから参照する。
データベースのPod(mariadb)
mariadbのconfigmap
configmapってのはPodが参照する環境変数の置き場みたいなもので名前空間ごとに定義できる。
minikubeでは１つしか名前空間とか定義してへんから、あんまり意識せずに使える。
docker-compose.ymlの中でENVとか書いてたりすると、configmapに書き出してくれる。
kubernetesだと使い方はこのへんにある。
gkeだと使い方はこのへんにある。
komposeが作ってくれたものを丸パクリしてて内容はこんな感じ。
apiVersion: v1
data:
MARIADB_DATABASE: nariDB_1st
MARIADB_PASSWORD: XXXXXX
MARIADB_ROOT_PASSWORD: XXXXXXXX
MARIADB_USER: nari
TZ: Asia/Tokyo
kind: ConfigMap
metadata:
creationTimestamp: null
labels:
io.kompose.service: sv-mariadb1011-txt
name: sv-mariadb11-txt
mariadbの場合は、ENVで定義したデータベース名・rootユーザのパスワード・一般ユーザとそのパスワードを書いておくと、初回起動時の初期化処理で設定やってくれる。
minikubeの場合はconfigmapとして定義しといたらええ。
パスワードはconfigmapじゃなくてsecretで定義したほうがええような気がするけど、目に見えへんから扱いにくいのでminikubeローカル環境ではパス。
mariadbのpv/pvc
永続化領域の解説がサイトにあるから、最初はこのへん読んだ。
MinikubeのVMはtmpfsで起動するため、ほとんどのディレクトリーは再起動しても持続しません (minikube stop)。 しかし、Minikubeは以下のホストディレクトリーに保存されているファイルを保持するように設定されています: /data /var/lib/minikube /var/lib/docker
minikubeで維持するフォルダは決まってるらしい。
pvには種類がある。
mysql/mariadbでpvc/pvはどう使うのか参考にさせてもらった。
作者さんありがとう。
pvcで要求して、pvを使うって感じか。
自分で使ってる内容はこんな感じ。
まずは設定ファイル置き場用。
kind: PersistentVolume
apiVersion: v1
metadata:
name: gvis-pv-mariadb1011conf # PVの名前
labels:
type: local
spec:
storageClassName: manual # PVCと一致させる必要がある
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce # 一つのノードからread/writeでマウントできるモード
hostPath:
path: "/data/gvis-pv-mariadb1011conf"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gvis-pv-mariadb1011conf-claim # PVCの名前
spec:
# storageClassName=manualのPVを探してマウントする
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi # PVが持っている容量のうち1GiBを使用する
データ置き場用にもういっちょ。
kind: PersistentVolume
apiVersion: v1
metadata:
name: gvis-pv-mariadb1011 # PVの名前
labels:
type: local
spec:
storageClassName: manual # PVCと一致させる必要がある
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce # 一つのノードからread/writeでマウントできるモード
hostPath:
path: "/data/gvis-pv-mariadb1011"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gvis-pv-mariadb1011-claim # PVCの名前
spec:
# storageClassName=manualのPVを探してマウントする
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi # PVが持っている容量のうち20GiBを使用する
mariadbのdeployment
一般的な定義を参考にさせてもらった。
作者さんありがとう。
使ってる内容はこんな感じ。
my.cnfとかに書きたい内容あるし、インポートの処理も使いたいからpvc/pvを使ってる。
apiVersion: apps/v1
kind: Deployment
metadata:
name: sv-mariadb1011
labels:
app: sv-mariadb1011
spec:
replicas: 1
selector:
matchLabels:
app: sv-mariadb1011
strategy:
type: Recreate
template:
metadata:
labels:
app: sv-mariadb1011
spec:
containers:
- env:
- name: MARIADB_DATABASE
valueFrom:
configMapKeyRef:
key: MARIADB_DATABASE
name: sv-mariadb11-txt
- name: MARIADB_PASSWORD
valueFrom:
configMapKeyRef:
key: MARIADB_PASSWORD
name: sv-mariadb11-txt
- name: MARIADB_ROOT_PASSWORD
valueFrom:
configMapKeyRef:
key: MARIADB_ROOT_PASSWORD
name: sv-mariadb11-txt
- name: MARIADB_USER
valueFrom:
configMapKeyRef:
key: MARIADB_USER
name: sv-mariadb11-txt
- name: TZ
valueFrom:
configMapKeyRef:
key: TZ
name: sv-mariadb11-txt
image: save-mariadb:gvis-saved
name: sv-mariadb1011
ports:
- containerPort: 3306
resources: {}
volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
- name: mariadb1011-persistent-storage1
mountPath: /var/lib/mysql
- name: mariadb1011-persistent-storage2
mountPath: /etc/mysql/conf.d
hostname: svmariadb1011
restartPolicy: Always
volumes:
- name: mariadb1011-persistent-storage1
persistentVolumeClaim:
claimName: gvis-pv-mariadb1011-claim
# name=gvis-pv-mariadb1011-claimを使って、マウントできるPVを探す
- name: mariadb1011-persistent-storage2
persistentVolumeClaim:
claimName: gvis-pv-mariadb1011conf-claim
# name=gvis-pv-mariadb1011conf-claimを使って、マウントできるPVを探す
mariadbのservice
内容はこんな感じ。
何番のポートを使うかってのを書いとく。
apiVersion: v1
kind: Service
metadata:
labels:
app: sv-mariadb1011
name: sv-mariadb1011
spec:
type: ClusterIP
ports:
- name: "13306"
port: 13306
targetPort: 3306
selector:
app: sv-mariadb1011
mariadbへのデータ流し込み
mysqlもmariadbも、データのエクスポートは簡単。
データベース作って、テーブル作って、レコードをinsertするsqlのテキストファイルが出力される。
postgresqlも同じ。
GCPのDBデータは、tar.gzで固めてコピーしてきたらlocal ubuntu22の中でそのまま使えるけど、minikubeにはそのまま持って来れず。
そこで、local ubuntu22の中のmariadbから、定期的に定義やデータをエクスポートする処理を復活させた。
このエクスポートをPodにインポートして使う。
Podの中で動かす処理はこのへんのリストア処理にある「4_nariDB_DjangoRecover.sh」とかをPodの中に置いといて使う。
エクスポート結果はwindowsホストからはMドライブとして見えるようにしてて、それをminikubeに取り込む処理をtera termマクロで書いて使うとデータの流し込みができる。
エクスポート結果をminikube環境にコピーして、pod/pv/pvcのあるフォルダに移動して作り直し、インポート終わったらmariadbの設定の一部とテーブルの件数を表示させてエクスポートされてきたファイルはデカいから潰す。
内容はこんな感じ。
include 'Y:_connect\connect\teraIni\gvis.ini'
SOURFILE1 = 'M:\nariDockerDat\cl_nari\nariDB_1st\FullBackup_nariDB_1st.sql'
DESTFILE1 = '/Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_1st.sql'
SOURFILE2 = 'M:\nariDockerDat\cl_nari\nariDB_Django\FullBackup_nariDB_Django.sql'
DESTFILE2 = '/Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_Django.sql'
; --- 接続 --------------
conSTR = 'gvis-mac.intra.gavann-it.com /ssh /2 /auth=password /user=nari /passwd='
strconcat conSTR gvis_macP
strconcat conSTR ' /F='
strconcat conSTR gvis_iPTH
strconcat conSTR 'gray.INI '
strconcat conSTR '/timeout='
strconcat conSTR gvis_TOUT
; ---debug --------------
; messagebox conSTR 'info'
connect conSTR
if result <> 2 goto end
wait "nari@gvis-mac ~ %"
scpsend SOURFILE1 DESTFILE1
scpsend SOURFILE2 DESTFILE2
wait "nari@gvis-mac"
sendln 'cd /Users/nari/Documents/personal/minikube'
wait "nari@gvis-mac"
sendln 'kubectl delete -f sv-mariadb1011-deployment.yaml'
wait "nari@gvis-mac"
sendln 'kubectl delete -f gvis-PersistentVol-mariadb1011conf.yaml'
wait "nari@gvis-mac"
sendln 'kubectl delete -f gvis-PersistentVol-mariadb1011.yaml'
wait "nari@gvis-mac"
sendln 'minikube ssh'
wait "$"
sendln 'sudo su -'
wait "#"
sendln 'cd /data'
wait "#"
sendln 'rm -fR ./gvis-pv-mariadb1011 ; rm -fR ./gvis-pv-mariadb1011conf ; sync ; sync '
wait "#"
sendln 'mkdir gvis-pv-mariadb1011conf ; mkdir gvis-pv-mariadb1011'
wait "#"
sendln 'cp -pR /minikubeMac/nariDockerDat/sv_mariadb11conf/* ./gvis-pv-mariadb1011conf/'
wait "#"
sendln 'exit'
wait "$"
sendln 'exit'
wait "nari@gvis-mac"
sendln 'kubectl create -f gvis-PersistentVol-mariadb1011conf.yaml'
wait "nari@gvis-mac"
sendln 'kubectl create -f gvis-PersistentVol-mariadb1011.yaml'
wait "nari@gvis-mac"
sendln 'kubectl create -f sv-mariadb1011-deployment.yaml'
wait "nari@gvis-mac"
sendln 'sleep 10'
wait "nari@gvis-mac"
sendln "kubectl exec -it `kubectl get pod | grep mariadb | awk '{print $1}'` -- bash"
wait "root@svmariadb1011"
sendln '/bin/sh /etc/mysql/conf.d/nari/fullback/2_fullRecover.sh'
wait "root@svmariadb1011"
sendln '/bin/sh /etc/mysql/conf.d/nari/fullback/4_nariDB_DjangoRecover.sh'
wait "root@svmariadb1011"
sendln 'rm /etc/mysql/conf.d/nari/FullBackup_nariDB_1st.sql'
wait "root@svmariadb1011"
sendln 'rm /etc/mysql/conf.d/nari/FullBackup_nariDB_Django.sql'
wait "root@svmariadb1011"
sendln 'mysql -unari -pXXXXXXXXX'
wait "MariaDB"
sendln "show variables like 'max_allowed_packet' ; "
wait "MariaDB"
sendln 'show databases ; '
wait "MariaDB"
sendln 'use nariDB_1st ; '
wait "MariaDB"
sendln 'select count(*) from GVIS_keihi ; '
wait "MariaDB"
sendln 'exit '
wait "nari@gvis-mac"
delSTR = 'rm -f '
strconcat delSTR DESTFILE1
sendln delSTR
wait "nari@gvis-mac"
delSTR = 'rm -f '
strconcat delSTR DESTFILE2
sendln delSTR
end
mariadbの動作確認
Pod単体の起動確認をたとえばwindows側からa5sql使ってやるとこうなる。
はい、できたー。
ここまで書いて、続きはまた今度。
