- 投稿日：2020-03-21T21:28:27+09:00
docker-compose buildでYou must use Bundler 2 or greater with this lockfile.とエラーが出た話
経緯
「既存の作成済のrailsアプリケーションにDockerを導入してみたい！！でも、いきなり導入していろいろ変なことになったら嫌だな」ということで、Railsチュートリアルの開発環境をDockerにしてみなイカ？という記事を参考にさせていただき、まずはrailsチュートリアルをdockerにのせようと、奮闘している最中、
You must use Bundler 2 or greater with this lockfile. ERROR: Service 'app' failed to build: The command '/bin/sh -c bundle install --jobs=4' returned a non-zero code: 20というエラーが。。
解決した方法
You must use Bundler 2 or greater with this lockfile.これは、Bundlerのバージョンが2以上を使わなければならなかったのに、Dockerのimageで1.X.Xを利用していたことが原因だったみたいです。
確かに、Gemfile.lockを見ると、一番最後の行に、BUNDLED WITH 2.1.4の記載が。。。
そこで、docker-compose buildした際に、bundlerをinstallすれば問題ないと知り、
Dockerfileにて~~~略~~~ RUN bundle installとしていたところを
~~~略~~~ RUN gem install bundler && bundle installのように、bundlerをインストールすることで解決しました！！
- 投稿日：2020-03-21T18:12:25+09:00
kubectlでやってることをcurlでやりたい
概要
kubernetesを運用する際に、アドオン的な感じで動的にPod(Kubernetes Resource)を生成するというユースケースを知った。そのため例えばPod内から新たにPodを生成するなどといった場合が考えられ、その際にkubectlをPod内から使用するケースやcurlなどの汎用的なツールを簡易的に使えるかを確認したくなった。
下記では、kubectl proxyを用いて、kubernetesクラスタ外からKubernetes APIをcurlを通して実行することで同様のことを確認した。Pod内から同様のことを行う際は、Kubernetes APIを実行するためのトークン 取得方法が異なっているので注意が必要。
Kubernetes APIとは
Kubernetes内のコンポーネント間の通信や捜査はすべてAPIを通して行われており、REST形式のAPIとなっています。
kubectlを用いることで大半の操作は行うことができますし、直接REST APIをcurlで叩くことでも同様の操作を行うことができます。
https://kubernetes.io/docs/reference/using-api/api-overview/
直接Kubernetes API叩いてみる
kubectl proxyなしの場合
なければクラスタ起動
kind create clusterクラスタ一覧確認
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'アクセスするクラスタ名を選択(自分の場合は、kindを使用しているのでこのクラスタ名を選択)
export CLUSTER_NAME="kind-kind"クラスタ名からアクセス先取得
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")アクセストークン 取得
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)kubernetes APIを実行
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "172.17.0.2:6443" } ] }kubectl proxyありの場合
kubectl proxyを起動
8001番ポートで動作していることを確認
kubectl proxy Starting to serve on 127.0.0.1:8001Kubernetes APIを叩いてみると、先ほどと同様の結果を取得できる
curl -X GET 127.0.0.1:8001/api { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "172.17.0.2:6443" } ] }試しにnginxのPodを動作させてみてから、Kubernetes APIでPodを確認してみる
k run nginx --image=nginx --restart=Never --dry-run -oyaml > nginx.yamlk apply -f nginx.yamlk get po NAME READY STATUS RESTARTS AGE nginx 0/1 ContainerCreating 0 1scurlでPod一覧取得してみるとjson形式で同様の情報が取得できる
curl -X GET http://127.0.0.1:8001/api/v1/namespaces/default/pods { "kind": "PodList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces/default/pods", "resourceVersion": "5973" }, "items": [ { "metadata": { "name": "nginx", "namespace": "default", "selfLink": "/api/v1/namespaces/default/pods/nginx", "uid": "119f6219-5ff3-4542-b785-e7532301a972", "resourceVersion": "5891", "creationTimestamp": "2020-03-21T06:08:56Z", "labels": { "run": "nginx" }, "annotations": { "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":null,\"labels\":{\"run\":\"nginx\"},\"name\":\"nginx\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx\",\"name\":\"nginx\",\"resources\":{}}],\"dnsPolicy\":\"ClusterFirst\",\"restartPolicy\":\"Never\"},\"status\":{}}\n" } }, "spec": { "volumes": [ { "name": "default-token-lh646", "secret": { "secretName": "default-token-lh646", "defaultMode": 420 } } ], "containers": [ { "name": "nginx", "image": "nginx", "resources": { }, ~中略~ } } ] }jsonだとkubectlの結果より見づらいのは仕方ないが、下記のようなツールでjson結果もある程度扱いやすくできる。
Macの場合下記のコマンドで導入できる。
brew install jidcurl -X GET http://127.0.0.1:8001/api/v1/namespaces/default/pods | jid下記のように対話的にjsonファイルを深掘りできる。
curlでPodの作成を試してみる
エンドポイントについてはKubernetes APIから確認することができる
Hwllo Worldとだけ出力するPodを作成する
curl -X POST -H 'Content-Type: application/yaml' -d ' apiVersion: v1 kind: Pod metadata: name: pod-example spec: containers: - name: ubuntu image: ubuntu:trusty command: ["echo"] args: ["Hello World"] restartPolicy: Never ' http://127.0.0.1:8001/api/v1/namespaces/default/pods実行結果
{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "pod-example", "namespace": "default", "selfLink": "/api/v1/namespaces/default/pods/pod-example", "uid": "4ac7cf5c-69b7-40f9-806d-582cafebd590", "resourceVersion": "8977", "creationTimestamp": "2020-03-21T06:50:46Z" }, "spec": { "volumes": [ { "name": "default-token-lh646", "secret": { "secretName": "default-token-lh646", "defaultMode": 420 } } ], "containers": [ { "name": "ubuntu", "image": "ubuntu:trusty", "command": [ "echo" ], "args": [ "Hello World" ], "resources": { }, ~中略~ }Podが作成されていることを確認
先ほど作成したnginxのpodに加えて、
ログにHello Worldが出力されていることも確認できる
k logs pod-example Hello WorldPod内からKubernetes APIを叩く方法
必要な権限を持ったSeriveAccountを作成(ついでにnamespaceなども作成)
k apply -f api.yamlNamespace切り替え
kubensは別途install必要(https://github.com/ahmetb/kubectx)
kubens mynamespaceCurlを叩くためのPodのyamlを生成
k run fedora --image=fedora --restart=Never --dry-run -oyaml -- /sbin/init > fedora.yaml出力したyamlに一部追記(tty, stdin, serviceAccountName)
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: fedora name: fedora spec: containers: - args: - /sbin/init image: fedora name: fedora resources: {} dnsPolicy: ClusterFirst restartPolicy: Never tty: true stdin: true serviceAccountName: mysa status: {}Podをデプロイ
k apply -f fedora.yamlPod内にアクセス
k exec -it fedora bashトークン を取得して、Kubernetes APIを実行
下記は、このコマンドを実行しているPod情報を取得する
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) NAMESPACE=mynamespace curl -sSk -H "Authorization: Bearer $KUBE_TOKEN" \ https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_PORT_443_TCP_PORT/api/v1/namespaces/$NAMESPACE/pods/$HOSTNAMEjsonで取得するためぱっと見わかるづらいが、k get po と同様の内容を取得できている。
{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "fedora", "namespace": "mynamespace", "selfLink": "/api/v1/namespaces/mynamespace/pods/fedora", "uid": "7c918fc0-f194-4729-896a-f52167c4a803", "resourceVersion": "17841", "creationTimestamp": "2020-03-21T08:51:57Z", "labels": { "run": "fedora" }, "annotations": { "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":null,\"labels\":{\"run\":\"fedora\"},\"name\":\"fedora\",\"namespace\":\"mynamespace\"},\"spec\":{\"containers\":[{\"args\":[\"/sbin/init\"],\"image\":\"fedora\",\"name\":\"fedora\",\"resources\":{},\"stdin\":true,\"tty\":true}],\"dnsPolicy\":\"ClusterFirst\",\"restartPolicy\":\"Never\",\"serviceAccountName\":\"mysa\"},\"status\":{}}\n" } }, "spec": { "volumes": [ { "name": "mysa-token-lt4gh", "secret": { "secretName": "mysa-token-lt4gh", "defaultMode": 420 } } ], "containers": [ { "name": "fedora", "image": "fedora", "args": [ "/sbin/init" ], "resources": { }, ~中略~ }まとめ
Kubernetes APIを知ることでkubectlでやっていることをcurlでも同様に行えることを確認した。
新たにPodなどを作る処理はPod内でもかけるため、動的に増加するリソースを制御・監視する方法を検討したい。
- 投稿日：2020-03-21T18:10:11+09:00
kubectlでやってることをcurlでやりたい
概要
kubernetesを運用する際に、アドオン的な感じで動的にPod(Kubernetes Resource)を生成するというユースケースを知った。そのため例えばPod内から新たにPodを生成するなどといった場合が考えられ、その際にkubectlをPod内から使用するケースやcurlなどの汎用的なツールを簡易的に使えるかを確認したくなった。
下記では、kubectl proxyを用いて、kubernetesクラスタ外からKubernetes APIをcurlを通して実行することで同様のことを確認した。Pod内から同様のことを行う際は、Kubernetes APIを実行するためのトークン 取得方法が異なっているので注意が必要。
Kubernetes APIとは
Kubernetes内のコンポーネント間の通信や捜査はすべてAPIを通して行われており、REST形式のAPIとなっています。
kubectlを用いることで大半の操作は行うことができますし、直接REST APIをcurlで叩くことでも同様の操作を行うことができます。
https://kubernetes.io/docs/reference/using-api/api-overview/
直接Kubernetes API叩いてみる
kubectl proxyなしの場合
なければクラスタ起動
kind create clusterクラスタ一覧確認
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'アクセスするクラスタ名を選択(自分の場合は、kindを使用しているのでこのクラスタ名を選択)
export CLUSTER_NAME="kind-kind"クラスタ名からアクセス先取得
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")アクセストークン 取得
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)kubernetes APIを実行
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "172.17.0.2:6443" } ] }## kubectl proxyありの場合
kubectl proxyを起動
8001番ポートで動作していることを確認
kubectl proxy Starting to serve on 127.0.0.1:8001Kubernetes APIを叩いてみると、先ほどと同様の結果を取得できる
curl -X GET 127.0.0.1:8001/api { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "172.17.0.2:6443" } ] }試しにnginxのPodを動作させてみてから、Kubernetes APIでPodを確認してみる
k run nginx --image=nginx --restart=Never --dry-run -oyaml > nginx.yamlk apply -f nginx.yamlk get po NAME READY STATUS RESTARTS AGE nginx 0/1 ContainerCreating 0 1scurlでPod一覧取得してみるとjson形式で同様の情報が取得できる
curl -X GET http://127.0.0.1:8001/api/v1/namespaces/default/pods { "kind": "PodList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces/default/pods", "resourceVersion": "5973" }, "items": [ { "metadata": { "name": "nginx", "namespace": "default", "selfLink": "/api/v1/namespaces/default/pods/nginx", "uid": "119f6219-5ff3-4542-b785-e7532301a972", "resourceVersion": "5891", "creationTimestamp": "2020-03-21T06:08:56Z", "labels": { "run": "nginx" }, "annotations": { "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":null,\"labels\":{\"run\":\"nginx\"},\"name\":\"nginx\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx\",\"name\":\"nginx\",\"resources\":{}}],\"dnsPolicy\":\"ClusterFirst\",\"restartPolicy\":\"Never\"},\"status\":{}}\n" } }, "spec": { "volumes": [ { "name": "default-token-lh646", "secret": { "secretName": "default-token-lh646", "defaultMode": 420 } } ], "containers": [ { "name": "nginx", "image": "nginx", "resources": { }, ~中略~ } } ] }jsonだとkubectlの結果より見づらいのは仕方ないが、下記のようなツールでjson結果もある程度扱いやすくできる。
Macの場合下記のコマンドで導入できる。
brew install jidcurl -X GET http://127.0.0.1:8001/api/v1/namespaces/default/pods | jid下記のように対話的にjsonファイルを深掘りできる。
curlでPodの作成を試してみる
エンドポイントについてはKubernetes APIから確認することができる
Hwllo Worldとだけ出力するPodを作成する
curl -X POST -H 'Content-Type: application/yaml' -d ' apiVersion: v1 kind: Pod metadata: name: pod-example spec: containers: - name: ubuntu image: ubuntu:trusty command: ["echo"] args: ["Hello World"] restartPolicy: Never ' http://127.0.0.1:8001/api/v1/namespaces/default/pods実行結果
{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "pod-example", "namespace": "default", "selfLink": "/api/v1/namespaces/default/pods/pod-example", "uid": "4ac7cf5c-69b7-40f9-806d-582cafebd590", "resourceVersion": "8977", "creationTimestamp": "2020-03-21T06:50:46Z" }, "spec": { "volumes": [ { "name": "default-token-lh646", "secret": { "secretName": "default-token-lh646", "defaultMode": 420 } } ], "containers": [ { "name": "ubuntu", "image": "ubuntu:trusty", "command": [ "echo" ], "args": [ "Hello World" ], "resources": { }, ~中略~ }Podが作成されていることを確認
先ほど作成したnginxのpodに加えて、
ログにHello Worldが出力されていることも確認できる
k logs pod-example Hello WorldPod内からKubernetes APIを叩く方法
必要な権限を持ったSeriveAccountを作成(ついでにnamespaceなども作成)
k apply -f api.yamlNamespace切り替え
kubensは別途install必要(https://github.com/ahmetb/kubectx)
kubens mynamespaceCurlを叩くためのPodのyamlを生成
k run fedora --image=fedora --restart=Never --dry-run -oyaml -- /sbin/init > fedora.yaml出力したyamlに一部追記(tty, stdin, serviceAccountName)
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: fedora name: fedora spec: containers: - args: - /sbin/init image: fedora name: fedora resources: {} dnsPolicy: ClusterFirst restartPolicy: Never tty: true stdin: true serviceAccountName: mysa status: {}Podをデプロイ
k apply -f fedora.yamlPod内にアクセス
k exec -it fedora bashトークン を取得して、Kubernetes APIを実行
下記は、このコマンドを実行しているPod情報を取得する
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) NAMESPACE=mynamespace curl -sSk -H "Authorization: Bearer $KUBE_TOKEN" \ https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_PORT_443_TCP_PORT/api/v1/namespaces/$NAMESPACE/pods/$HOSTNAMEjsonで取得するためぱっと見わかるづらいが、k get po と同様の内容を取得できている。
{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "fedora", "namespace": "mynamespace", "selfLink": "/api/v1/namespaces/mynamespace/pods/fedora", "uid": "7c918fc0-f194-4729-896a-f52167c4a803", "resourceVersion": "17841", "creationTimestamp": "2020-03-21T08:51:57Z", "labels": { "run": "fedora" }, "annotations": { "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":null,\"labels\":{\"run\":\"fedora\"},\"name\":\"fedora\",\"namespace\":\"mynamespace\"},\"spec\":{\"containers\":[{\"args\":[\"/sbin/init\"],\"image\":\"fedora\",\"name\":\"fedora\",\"resources\":{},\"stdin\":true,\"tty\":true}],\"dnsPolicy\":\"ClusterFirst\",\"restartPolicy\":\"Never\",\"serviceAccountName\":\"mysa\"},\"status\":{}}\n" } }, "spec": { "volumes": [ { "name": "mysa-token-lt4gh", "secret": { "secretName": "mysa-token-lt4gh", "defaultMode": 420 } } ], "containers": [ { "name": "fedora", "image": "fedora", "args": [ "/sbin/init" ], "resources": { }, ~中略~ }まとめ
Kubernetes APIを知ることでkubectlでやっていることをcurlでも同様に行えることを確認した。
新たにPodなどを作る処理はPod内でもかけるため、動的に増加するリソースを制御・監視する方法を検討したい。
- 投稿日：2020-03-21T16:51:26+09:00
[Docker] Cheat sheet
Docker
全コンテナの一覧表示
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 20d739e7aa4c hmiyakoshi0803/neo4j:4.0.2 "/sbin/tini -g -- /d…" About a minute ago Exited (0) 7 seconds ago docker_db_1停止しているコンテナの一括削除
-fオプションを付けると確認されない (Do not prompt for confirmation)$ docker container prune -f Deleted Containers: 20d739e7aa4cac4209c50b00ba5c357432b0c4124354f23c92773d3c74f189ec Total reclaimed space: 115.1MBdocker-compose
dockerイメージビルド
--no-cacheオプションを付けないとキャッシュがあればそちらを優先的に使ってビルドする- Dockerfile変更時は付けた方が良い
$ docker-compose build --no-cacheイメージ構築&コンテナ構築&実行
-dオプションを付けるとバックグラウンド実行される
---buildオプションを付けることで、イメージの構築から、コンテナの構築・起動までを行う$ docker-compose up -d --build実行停止&コンテナ削除&ネットワーク削除
$ docker-compose down
--rmi allを付けることでイメージも削除可能--volumesを付けることでvolumesセクションに書かれた名前付きボリュームとコンテナにアタッチされたanonymous volumeが削除される$ docker-compose down --rmi all --volumes参考
docker-composeでbuildする時にcacheを使わない
docker-composeupとかbuildとかstartとかの違いを理解できていなかったのでまとめてみた。
Docker一括削除コマンドまとめ
《滅びの呪文》Docker Composeで作ったコンテナ、イメージ、ボリューム、ネットワークを一括完全消去する便利コマンドおまけ
docker-composeと打つのが長いので、alias登録してやる$ cat ~/.bash_profile ・ ・ ・ # alias alias dc='docker-compose'以上
- 投稿日：2020-03-21T15:51:26+09:00
CircleCi2.0でphpunit実行時に Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate... が出たときの対処法
やってもダメだったこと
php.inimemory_limit = -1 // メモリの制限を無くす.circleci/config.yml- image: circleci/mysql:5.7 command: [--max_allowed_packet=32M] // mysqlのパケット制限を増やす解決策
.circleci/config.yml- run: command: vendor/bin/phpunit -d memory_limit=512Mphpunitの実行オプションに-d memory_limit=512Mをつけることで解決しました。
なかなか解決策が見つからなくて、かなりハマってしまいました（汗）
この記事が誰かのお役に立てたら何よりです。参考にさせていただいた記事
https://qiita.com/pinekta/items/4ece0c88402610f874d0
↓こちらに解決策が載ってました。
https://discuss.circleci.com/t/php-memory-size/7602
- 投稿日：2020-03-21T15:22:34+09:00
Docker で CentOS Linux 8 環境を構築して Apache HTTP Server を起動する
概要
- macOS 上の Docker で CentOS Linux 8 環境を構築する
- Apache HTTP Server を起動してコンテナ内外からアクセスする
今回の環境
- macOS Catalina
- Docker Desktop Community 2.2.0.4
- Docker 19.03.8
- CentOS Linux 8
- Apache HTTP Server 2.4.37
$ docker --version Docker version 19.03.8, build afacb8bCentOS Linux 8 イメージを Docker Hub から取得
docker pull コマンドでイメージを取得する。
$ docker pull centos:centos8 centos8: Pulling from library/centos 8a29a15cefae: Pull complete Digest: sha256:fe8d824220415eed5477b63addf40fb06c3b049404242b31982106ac204f6700 Status: Downloaded newer image for centos:centos8 docker.io/library/centos:centos8インストール可能な CentOS Linux のイメージは centos Tags - Docker Hub から探すことができる。
コンテナを作成して起動
コンテナに foobar という名前を割り当てて、バックグラウンドで実行する。
ここではコンテナの80番ポートをホストの8080番ポートに割り当てている。$ docker run --detach --name foobar --privileged --publish=8080:80 centos:centos8 /sbin/initrun — Docker-docs-ja 17.06.Beta ドキュメント
docker run コマンドは、まず指定されたイメージ上に書き込み可能なコンテナ・レイヤを create （作成）します。それから、指定されたコマンドを使って start （開始）します。この docker run は、 API の /containers/create の後で /containers/(id)/start を実行するのと同じです。
docker run コマンドに --privileged と /sbin/init を指定しないと、systemd を使用する際に以下のようなエラーメッセージが表示されて systemd が使用できなくなるので注意する。
System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is downCentOS Linux 8 にログイン
docker exec コマンドを使用して、起動したコンテナ内にて bash シェルを実行する。
これで CentOS Linux 8 内に入ることができる。$ docker exec -it foobar bashCentOS Linux 8 を使用
シェル内で OS バージョン等を確認する。
[root@29d737551a55 /]# cat /etc/os-release NAME="CentOS Linux" VERSION="8 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="8"[root@29d737551a55 /]# uname -a Linux 29d737551a55 4.19.76-linuxkit #1 SMP Thu Oct 17 19:31:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linuxvim などのよく使うと思われるソフトウェアがインストールされていない。
[root@29d737551a55 /]# vim bash: /usr/bin/vim: No such file or directoryvim をインストールする。
[root@29d737551a55 /]# dnf install vim[root@29d737551a55 /]# vim --version VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 11 2019 19:08:24) Included patches: 1-1763シェルから抜けるには exit コマンドを使う。
[root@29d737551a55 /]# exit exitコンテナを停止
docker stop コマンドで起動しているコンテナを停止できる。
$ docker stop foobarコンテナの情報を確認
docker ps コマンドでコンテナの情報を表示できる。
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 29d737551a55 centos:centos8 "/sbin/init" 46 minutes ago Exited (137) 19 seconds ago foobarコンテナを起動
docker start コマンドで停止したコンテナを起動できる。
$ docker start foobarApache HTTP Server をインストールする
コンテナ内にシェルを起動してログインする。
$ docker exec -it foobar bashdnf コマンドで httpd パッケージをインストールする。
[root@29d737551a55 /]# dnf install httpdこれで Apache HTTP Server がインストールできた。
バージョンを確認する。[root@29d737551a55 /]# httpd -v Server version: Apache/2.4.37 (centos) Server built: Dec 23 2019 20:45:34systemd で管理するように設定する。
[root@29d737551a55 /]# systemctl enable httpd Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.systemctl start コマンドで Apache HTTP Server を起動する。
[root@29d737551a55 /]# systemctl start httpd初期設定ではドキュメントルートが /var/www/html/ になっているので /var/www/html/index.html に HTML ファイルを作成する。
[root@29d737551a55 /]# vi /var/www/html/index.html今回は以下の内容を記述した。
<html> <body> Hello, World! </body> </html>curl コマンドでアクセスすると Apache HTTP Server が HTML ファイルを出力する。
[root@29d737551a55 /]# curl -i http://localhost/ HTTP/1.1 200 OK Date: Sat, 21 Mar 2020 06:00:04 GMT Server: Apache/2.4.37 (centos) Last-Modified: Sat, 21 Mar 2020 05:59:52 GMT ETag: "2d-5a1571c48ab9e" Accept-Ranges: bytes Content-Length: 45 Content-Type: text/html; charset=UTF-8 <html> <body> Hello, World! </body> </html>今回はコンテナの80番ポートを Docker ホスト側の8080番ポートに割り当てている。
コンテナ外からホスト側の8080番ポートにアクセスするとコンテナの80番ポートにつながる。$ curl -i http://localhost:8080/ HTTP/1.1 200 OK Date: Sat, 21 Mar 2020 06:01:21 GMT Server: Apache/2.4.37 (centos) Last-Modified: Sat, 21 Mar 2020 05:59:52 GMT ETag: "2d-5a1571c48ab9e" Accept-Ranges: bytes Content-Length: 45 Content-Type: text/html; charset=UTF-8 <html> <body> Hello, World! </body> </html>参考資料
- 投稿日：2020-03-21T13:14:39+09:00
Ubuntu 18.04にDockerでGROWIを構築する
概要
以前，CentOS上にGROWIをDockerで構築する手順を公開したがUbuntuでの構築方法もまとめてみた．
CentOSでの構築手順 ↓
GROWIをDockerで構築する環境
環境はESXi6.7上にUbuntu 18.04の仮想マシンをたてて，その上に構築する
Software Version Ubuntu 18.04 Docker 19.03.8 Docker-Compose 1.25.1 パッケージのアップデート
sudo apt update sudo apt upgradedockerのインストール
1. Repositoryをアップデートする
- パッケージをインストールする
sudo apt install -y \ apt-transport-https \ ca-certificates \ curl \ software-properties-common
- DockerのGPG keyを追加する
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
- Repository( stable ) を追加する
sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable"
- パッケージのupdateを実施する
sudo apt update2. dockerをインストールする
- インストールする
sudo apt install -y docker-ce
- dockerの起動確認を行う
$ sudo systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: e Active: active (running) since Sat 2020-03-21 12:25:35 JST; 28min ago Docs: https://docs.docker.com Main PID: 28276 (dockerd) Tasks: 31 CGroup: /system.slice/docker.service tq 3549 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port tq 3603 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port mq28276 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/contai3. 一般ユーザでもsudo無しでdockerを使えるようにする
- 一般ユーザをDocker groupに追加する
※の部分を変更する．この時「<,>」は必要ありません
sudo gpasswd -a <yourusername> docker
- dockerが使用するソケットを一般ユーザでも読み込み出来るようにする
sudo chmod 666 /var/run/docker.sockdocker-composeのインストール
- 最新のバージョンを確認
- 下記コマンドでダウンロード
export compose='1.25.1'
- /usr/local/bin/ 配下にダウンロード
sudo curl -L https://github.com/docker/compose/releases/download/${compose}/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
- 実行権限の付与
sudo chmod 0755 /usr/local/bin/docker-compose
- versionの確認
$ docker-compose -v docker-compose version 1.25.1, build a82fef07gitをインストールする
- すでにインストール済みの場合もあるが一応．．．
sudo apt install gitGROWIの構築
これで下準備は整ったのでGrowiをインストールしていきます．
1. GROWIをクローンする
今回は/opt以下に構築していきます．
# cd /opt # git clone https://github.com/weseek/growi-docker-compose.git growi # cd growi2. docker-compose .ymlを編集
続いてdocker-compose.ymlを編集していきます．
- サーバの外からもアクセスしたいので127.0.0.1は削除する
- 「FILE_UPLOAD=local」はコメントアウトを外すことでローカル(Docker内)に画像が保存できる
- 「elasticsearch:」の"ES_JAVA_OPTS=-Xms256m -Xmx256m"は"ES_JAVA_OPTS=-Xms512m -Xmx512m"にしておき，メモリに余裕がある場合は"ES_JAVA_OPTS=-Xms2g -Xmx2g"にしておいた方が良い．(メモリを少なく設定するとElasticsearchが起動しないことがある)
version: '3' services: app: build: context: . dockerfile: ./Dockerfile ports: # - 127.0.0.1:3000:3000 # localhost only by default - 3000:3000 # localhost only by default links: - mongo:mongo - elasticsearch:elasticsearch depends_on: - mongo - elasticsearch environment: - MONGO_URI=mongodb://mongo:27017/growi - ELASTICSEARCH_URI=http://elasticsearch:9200/growi - PASSWORD_SEED=changeme # - FILE_UPLOAD=mongodb # activate this line if you use MongoDB GridFS rather than AWS # - FILE_UPLOAD=local # activate this line if you use local storage of server rather than AWS # - MATHJAX=1 # activate this line if you want to use MathJax # - PLANTUML_URI=http:// # activate this line and specify if you use your own PlantUML server rather than public plantuml.com # - HACKMD_URI=http:// # activate this line and specify HackMD server URI which can be accessed from GROWI client browsers # - HACKMD_URI_FOR_SERVER=http://hackmd:3000 # activate this line and specify HackMD server URI which can be accessed from this server container # - FORCE_WIKI_MODE='public' # activate this line to force wiki public mode # - FORCE_WIKI_MODE='private' # activate this line to force wiki private mode command: "dockerize -wait tcp://mongo:27017 -wait tcp://elasticsearch:9200 -timeout 60s npm run server:prod" restart: unless-stopped volumes: - growi_data:/data mongo: image: mongo:3.6 restart: unless-stopped volumes: - mongo_configdb:/data/configdb - mongo_db:/data/db elasticsearch: build: context: ./elasticsearch dockerfile: ./Dockerfile environment: - bootstrap.memory_lock=true # - "ES_JAVA_OPTS=-Xms256m -Xmx256m" # increase amount if you have enough memory - "ES_JAVA_OPTS=-Xms512m -Xmx512m" # increase amount if you have enough memory ulimits: memlock: soft: -1 hard: -1 restart: unless-stopped volumes: - es_data:/usr/share/elasticsearch/data - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml volumes: growi_data: mongo_configdb: mongo_db: es_data:編集を終えたら保存しましょう
3. 起動
ここまで来たら後は起動するだけ
# docker-compose up起動後
動作が安定するまでしばらくかかります．
http://{サーバのIP}:3000/
にアクセスすると初回画面が表示されますので，ユーザ情報を入力します．
ここで登録したユーザは自動的に管理者権限が付与されます．
CodiMD連携(Option)
上記まででGROWIが使用可能となります．ここからはCodiMDと連携して複数同時編集を可能にします．機能の紹介はGROWIのドキュメントをご覧ください．
1. docker-compose.override.ymlファイルをdocker-compose.ymlと同じ階層にコピーする
- 作業前にGROWIが起動している場合は
docker-compose stopでアプリケーションを停止させます．GROWIをDockerでインストールするとGROWIフォルダ内に「examples」というフォルダがあり，examplesフォルダの中に「integrate-with-hackmd」フォルダがあり，その中に「docker-compose.override.yml」というファイルがあります．そのファイルをdocker-compose.ymlファイルと同じ階層にコピーします．
# cp /opt/growi/examples/integrate-with-hackmd/docker-compose.override.yml /opt/growi/2. docker-compose.override.ymlを編集する
- 「GROWI_URI」はブラウザでGROWIにアクセスするURLを入力します．例：http://{サーバのIP}:3000
- サーバ以外で使用したいので172.0.0.1は削除します．
version: '3' services: ## # HackMD(CodiMD) container # see https://github.com/hackmdio/codimd#configuration # hackmd: build: context: ./hackmd environment: - GROWI_URI=http://192.168.0.101:3000 - CMD_DB_URL=mysql://hackmd:hackmdpass@mariadb:3306/hackmd - CMD_CSP_ENABLE=false ports: # - 172.0.0.1:3100:3000 # localhost only by default - 3100:3000 # localhost only by default depends_on: - mariadb restart: unless-stopped ## # MariaDB # see https://hub.docker.com/_/mariadb/ mariadb: image: mariadb:10.3 command: mysqld --character-set-server=utf8 --collation-server=utf8_general_ci environment: - MYSQL_USER=hackmd - MYSQL_PASSWORD=hackmdpass - MYSQL_DATABASE=hackmd - MYSQL_RANDOM_ROOT_PASSWORD=true restart: unless-stopped volumes: - mariadb_data:/var/lib/mysql volumes: mariadb_data:編集を終えたら保存します．
3. docker-compose.ymlを編集する
- 「HACKMD_URI」と「HACKMD_URI_FOR_SERVER」のコメントアウトを外す
- 「HACKMD_URI」にはブラウザでCodiMDにアクセスするURLを入力します．例：http://{サーバのIP}:3100
version: '3' services: app: build: context: . dockerfile: ./Dockerfile ports: - 3000:3000 # localhost only by default links: - mongo:mongo - elasticsearch:elasticsearch depends_on: - mongo - elasticsearch environment: - MONGO_URI=mongodb://mongo:27017/growi - ELASTICSEARCH_URI=http://elasticsearch:9200/growi - PASSWORD_SEED=changeme # - FILE_UPLOAD=mongodb # activate this line if you use MongoDB GridFS rather than AWS # - FILE_UPLOAD=local # activate this line if you use local storage of server rather than AWS # - MATHJAX=1 # activate this line if you want to use MathJax # - PLANTUML_URI=http:// # activate this line and specify if you use your own PlantUML server rather than public plantuml.com - HACKMD_URI=http://192.168.0.101:3100 # activate this line and specify HackMD server URI which can be accessed from GROWI client browsers # - HACKMD_URI_FOR_SERVER=http://hackmd:3000 # activate this line and specify HackMD server URI which can be accessed from this server container # - FORCE_WIKI_MODE='public' # activate this line to force wiki public mode # - FORCE_WIKI_MODE='private' # activate this line to force wiki private mode command: "dockerize -wait tcp://mongo:27017 -wait tcp://elasticsearch:9200 -timeout 60s npm run server:prod" restart: unless-stopped volumes: - growi_data:/data mongo: image: mongo:3.6 restart: unless-stopped volumes: - mongo_configdb:/data/configdb - mongo_db:/data/db elasticsearch: build: context: ./elasticsearch dockerfile: ./Dockerfile environment: - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" # increase amount if you have enough memory ulimits: memlock: soft: -1 hard: -1 restart: unless-stopped volumes: - es_data:/usr/share/elasticsearch/data - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml volumes: growi_data: mongo_configdb: mongo_db: es_data:編集を終えたら保存します．
4. 起動
ここまで来たらGROWIと同様に起動します．
# docker-compose up自動的にCodiMDがインストールされ起動します．
- CodiMDには1GBほどのメモリを消費するため，elasticsearchに割り当てたメモリによっては起動しないことがあるため注意
5. サイトURLの設定
ブラウザからGROWIにアクセスし，「管理 > アプリ設定 > サイトURL設定」に進む．
「Database」の項目に先ほどdocker-compose.override.ymlのGROWI_URIで設定したアドレスを入力し「更新」をクリックする．
6. 使用方法
- 「HackMD」をクリックする
- Start to edit with HackMDをクリックする
- 下記のような画面が表示されればOK
注意
新規ページの場合は先にGROWIのエディタで何か入力し一旦ページを作成しないとHackMDモードでの編集ができない．
Sidebar(Option)
- GROWIに正式に実装されているわけではないが以下のページを参考にさせていただき，Sidebarを実装しました．
- 管理 > カスタマイズ > カスタムスクリプトに以下のコードを記載することでSidebarが使用できます．
// sidebarのリンク var links = [ ["/sample1", "sample 1"], ["/sample2", "sample 2"], ["/admin/customize", "(customize this)"], ] /* sidebarにリンク作る */ var sidemenu = document.querySelector('#side-menu'); if (sidemenu) { var li = function(href, name){ return '<li class="tbd"><a href="' + href + '">' + name + '</a></li>' } innerHTML = "" for (var i=0; i<links.length; i++){ innerHTML += li(links[i][0], links[i][1]) } sidemenu.innerHTML = innerHTML; }まとめ
UbuntuでもGROWIを構築することができた．
参考
dockerのインストール関連
Ubuntu 18.04にDockerをインストールする(+docker-composeも)
gitインストール
growiインストール
- 投稿日：2020-03-21T13:11:57+09:00
兵庫県のCOVID19感染者状況のGraphQL APIを公開してみた。(その2)
宣伝
兵庫県のコロナウイルス特設サイトが公開中
https://stop-covid19-hyogo.org/
僕の公開しているGraphQL APIとは今のところ別働で動いていますが
かなり参考にさせて頂いておりますのでご紹介しておきます。hyogo.covid19-api
api内訳
readInfectedPeoples
感染者情報一覧取得クエリ
https://web.pref.hyogo.lg.jp/kk03/corona_kanjyajyokyo.html
上記のページに掲載されている感染者情報のエクセルファイルを30分おきに
コンテナ内にダウンロード。
そのファイルを読み込みPostgreSQLにデータを挿入します。
gqlgenで立てたGraphQLサーバーでgormを使ってPostgreSQLからデータを取得し配信しています。GraphQLのフィールドとエクセルファイルとの関連
エクセルの「認定こども園」以降のデータはcluster_placesというサブコレクションクエリで読み込めます。
番号 確認日 年代 性別 管轄 居住地 職業 発症日 渡航歴 備考欄 no confirmed_date age_group sex jurisdiction residence occupation onset_date travel_history remarks 取得例
全フィールド取得クエリ例
uuidによるidフィールドもありますがプレイグラウンドで試す際は長すぎて見づらくなるので
ここではidを含めないクエリを貼っておきます。query{ readInfectedPeoples{ no confirmed_date age_group sex jurisdiction residence occupation onset_date travel_history remarks cluster_places{ no label is_relation } } }readExamOverviews
https://web.pref.hyogo.lg.jp/kk03/corona_hasseijyokyo.html
上記のページ、「発生状況」すぐ下のpdfファイルを30分おきに
コンテナ内にダウンロード。
そのファイルを読み込みPostgreSQLにデータを挿入します。
gqlgenで立てたGraphQLサーバーでgormを使ってPostgreSQLからデータを取得し配信しています。関連しているデータ
取得例
全フィールド取得クエリ例
query{ readExamOverviews{ no label count } }readExamDetails
https://web.pref.hyogo.lg.jp/kf16/singatakoronakensa.html
上記のバーチャート下部のテーブルタグを30分おきにスクレイピング
抽出したデータをPostgreSQLにデータを挿入します。
gqlgenで立てたGraphQLサーバーでgormを使ってPostgreSQLからデータを取得し配信しています。関連しているデータ
取得例
全フィールド取得クエリ例
query{ readExamDetails{ no date exam_count positive_count } }まとめ
今のところは兵庫県サイトに掲載されている内容を
ほぼ、そのまま返すだけのapiになっています。
何かアイデアが閃けばの話ですが
別コンテナで更にデータ加工させるなんて事も挑戦できればやってみようかと
将来的にはAI乗っけたコンテナで解析した結果をGraphQLでサーブするような
ものも作れるならやってみたい
マシンスペックかなり必要なんだろうか？
- 投稿日：2020-03-21T11:59:16+09:00
Docker 7歳の誕生日おめでとう！
これはなに？
ただDockerの誕生日を祝うだけの記事です
$ docker run -it lukaszlach/7th .---, .---, /# `\ .---, /# `\ | | /# `\ | | '. _/ .---, | | '. _/ .---, `(^ /# `\ '. _/ `(^ /# `\ ) | | `(^ ) | | ( '. _/ ) ( '. _/ `(^ ( `(^ ) ) ( ( .---, .---, /# `\ HAPPY 7th BIRTHDAY /# `\ | | Docker | | '. _/ '. _/ `(^ * * * `(^ ) *|_*|_*|*_ ) ( .-'`|* |* |*| `'-. ( |`-............-'| | | \ _ .-. _ / ,-|'-' '-' '-' '-'|-, /` \._ _./ `\ "._ `""""""""""` _." `''--..........--''` https://docker.com/birthday
- 投稿日：2020-03-21T10:25:02+09:00
dockerのvolumeとbindmountsの違い
この記事の目的
dockerのvolumeとbindmountsの違いについてまとめる
volumeとは
https://docs.docker.com/storage/volumes/
dbなどのデータを永続化させるためのものでbindmountと違うのはbindmoutはhostマシーンにデータを置くのに対してvolumeはdocker上に置くので完全に他のcontainerと独立できる。
bind mountとは
https://docs.docker.com/storage/bind-mounts/
補足：tmpfsマウント
実はtmpfsマウントと言うのもあってこれはhostマシーンにもvolumeにも保存しないでメモリに保存されると言うもの。セキュリティ的にどちらにも置けないと言う特殊状況でのみ使うものなのであまり関係ない。
- 投稿日：2020-03-21T01:36:12+09:00
aplineのタイムゾーンを設定する
goでtime.Now()するとUTCで困った
なにも考えず(知らずに)にdockerfileを以下のように書いていた
FROM golang:1.13 as builder WORKDIR /go/src/hoge ENV GO111MODULE on COPY go.mod . COPY go.sum . RUN go mod download COPY . . FROM alpine:3.9 COPY --from=builder /go/src/hoge/main /usr/local/bin/main EXPOSE 8080 ENTRYPOINT ["/usr/local/bin/main"]するとgoでtime.Now()したときにUTCが帰ってくる
サーバも当然こうなる/ # date Fri Mar 20 16:05:22 UTC 2020WEBアプリはJSTで色々計算したいので無理やりこう書いてやれば変換できる
//jst > utc jst, _ := time.LoadLocation("Asia/Tokyo") now := time.Now() //utc nowJST := now.In(jst).Format("2006/01/02")と思ったけど
time.LoadLocation("Asia/Tokyo")ここでzoneinfoが無いとエラーになるので
まずは無理やりmacの中のzoneinfoをコピーして今感じにdockerを修正FROM alpine:3.9 COPY --from=builder /go/src/go-larn/main /usr/local/bin/main #追加 ADD ./Tokyo.tar.gz / EXPOSE 8080 ADD ./views /views ENTRYPOINT ["/usr/local/bin/main"]これで無理やりgoでUTCからJSTに変換できるようになる。
と長い前置きはここまで。
dockerを修正してtimezoneを設定
やりたいことは２つ
- timezoneの設定
- zonefileの追加
FROM alpine:3.9 COPY --from=builder /go/src/go-larn/main /usr/local/bin/main # zonefileの追加 RUN apk add tzdata # timezoneを ENV TZ=Asia/Tokyo EXPOSE 8080 ADD ./views /views ENTRYPOINT ["/usr/local/bin/main"]起動後に実際にサーバに入って確認
/ # date Sat Mar 21 01:27:02 JST 2020ちゃんと修正されていますね。
あとはgoのソース直さないと・・・^^;
- 投稿日：2020-03-21T01:36:12+09:00
alpineのタイムゾーンを設定する
goでtime.Now()するとUTCで困った
なにも考えず(知らずに)にdockerfileを以下のように書いていた
FROM golang:1.13 as builder WORKDIR /go/src/hoge ENV GO111MODULE on COPY go.mod . COPY go.sum . RUN go mod download COPY . . FROM alpine:3.9 COPY --from=builder /go/src/hoge/main /usr/local/bin/main EXPOSE 8080 ENTRYPOINT ["/usr/local/bin/main"]するとgoでtime.Now()したときにUTCが帰ってくる
サーバも当然こうなる/ # date Fri Mar 20 16:05:22 UTC 2020WEBアプリはJSTで色々計算したいので無理やりこう書いてやれば変換できる
//jst > utc jst, _ := time.LoadLocation("Asia/Tokyo") now := time.Now() //utc nowJST := now.In(jst).Format("2006/01/02")と思ったけど
time.LoadLocation("Asia/Tokyo")ここでzoneinfoが無いとエラーになるので
まずは無理やりmacの中のzoneinfoをコピーして今感じにdockerを修正FROM alpine:3.9 COPY --from=builder /go/src/go-larn/main /usr/local/bin/main #追加 ADD ./Tokyo.tar.gz / EXPOSE 8080 ADD ./views /views ENTRYPOINT ["/usr/local/bin/main"]これで無理やりgoでUTCからJSTに変換できるようになる。
と長い前置きはここまで。
dockerを修正してtimezoneを設定
やりたいことは２つ
- timezoneの設定
- zonefileの追加
FROM alpine:3.9 COPY --from=builder /go/src/go-larn/main /usr/local/bin/main # zonefileの追加 RUN apk add tzdata # timezoneを ENV TZ=Asia/Tokyo EXPOSE 8080 ADD ./views /views ENTRYPOINT ["/usr/local/bin/main"]起動後に実際にサーバに入って確認
/ # date Sat Mar 21 01:27:02 JST 2020ちゃんと修正されていますね。
あとはgoのソース直さないと・・・^^;
- 投稿日：2020-03-21T00:15:20+09:00
Synology Dockerでのjenkinsの起動オプション
前提
Synology NAS DS218+で遊んでいます。
NAS ：Synology DiskStation 218+
RAM：10GB（2GB+8GB）
HDD：4TB + 3TB8GBはインストールはできるけどサポート外になるのでお気をつけて
Synology Docker では、使えないオプションを設定するので、sshで接続してコマンドを叩いてやります。概要
Synology Docker での jenkins 起動オプションを考えてみた
詳細
Docker jenkins から Docker コンテナを起動するための設定
sudo
-u root
-v /var/run/docker.sock:/var/run/docker.sockjenkinsの時間を日本時間にしたい
-e TZ=Asia/Tokyo8080ポートと50000ポートをbridgeの別ポート番号に設定
-p xxxxx:8080 -p zzzzzz:50000jenkinsのjenkins_homeをSynology NASの共有フォルダ[docker]以下に設定する
事前に[docker/jenkins_home]を[volume1]に作成し(もちろんその他のvolumeでも良い)
-v /volume1/docker/jenkins_home:/var/jenkins_home
-v /volume1/docker/jenkins_home/workspace:/var/jenkins_home/workspacework_spaceもNASのフォルダに保存しておく( jenkins_home以下なので、本来要らないはずなのになぁ... )
まとめるとこんな感じ
sudo docker run -u root -d -e TZ=Asia/Tokyo -p xxxxx:8080 -p zzzzz:50000 --name jenkins-blueocean_Test -v /volume1/docker/jenkins_home:/var/jenkins_home -v /volume1/docker/jenkins_home/workspace:/var/jenkins_home/workspace -v /var/run/docker.sock:/var/run/docker.sock jenkinsci/blueoceanそれでは、すばらしいSynology NASライフを