What's New Qiita

20201006のdockerに関する記事は14件です。

  • 投稿日：2020-10-06T23:53:40+09:00

【Docker】docker-compose上のRailsアプリのDBデータをバックアップ＆リストアする方法【MySQL】

現在業務委託でRailsアプリを使ってスクレイピングでデータ収集のお手伝いをさせていただいてるのですが、Docker環境を使っているため何かの拍子にうっかりvolume等を削除してしまったら大変なので、処理が終わるたびにデータのバックアップを取ってます。（レコード数33万件ほどある）

その方法をご紹介します！

バックアップ手順

バックアップデータを突っ込みたいファイルをRailsのrootディレクトリにつくり以下のコマンドを実行する。

$ docker exec -it CONTAINER_NAME（例:myapp_db_1） mysqldump DATABASE_NAME(例:myapp_developmentなど) > backup.sql

リストア(インポート）手順

取り込みたいバックアップファイル（dump.sql)をRailsのrootディレクトリにつくり以下のコマンドを実行する。

$ docker cp dump.sql mydocker_db_1:/tmp/dump.sql
$ docker exec -it myapp_db_1 bash
$ mysql -u USER_NAME -p -h HOST_NAME(database.ymlのhost名,dbとか) DB_NAME(myapp_developmentなど) < /tmp/dump.sql

docker exec -it myapp_db_1 bashでコンテナ内に入り、mysqlコマンドでインポートできます！

今後はデータのバックアップも自動化できればなおいいと思うので挑戦していきたいです！

以上です！

読んでいただきありがとうございます！

ご指摘などあればコメントいただけると嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T23:47:26+09:00

UbuntuにDockerでZabbixを入れて、同じホストでDockerを監視する

環境

環境 バージョン
OS Ubuntu 20.04 LTS
monitoringartist/dockbix-xxl latest
monitoringartist/dockbix-agent-xxl-limited latest

補足

dockbixは、dockerのzabbixで他のdockerプロセスを監視できるようになっているzabbix。

入れるまで

こちらの方の記事が良いです。
https://qiita.com/ko-he-8/items/c88c00dbc4e4f8b868b8

文字化け対応

sudo yum -y install ipa-gothic-fonts ipa-mincho-fonts ipa-pgothic-fonts ipa-pmincho-fonts
mv /usr/local/src/zabbix/frontends/php/assets/fonts/DejaVuSans.ttf DejaVuSans.bk
ln -s /usr/share/fonts/ipa-pgothic/ipagp.ttf /usr/local/src/zabbix/frontends/php/assets/fonts/DejaVuSans.ttf
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T22:42:35+09:00

IBM Cloud Shellを使ってCode Engineでアプリケーションを起動する

前提

先日書いた「IBM Cloud CLIを使ってCode Engineでアプリケーションを起動する」では、PCにインストールするIBM Cloud CLIを使用しました。ここでは、IBM Cloud Shellを使って、IBM Cloud Code Engineでコンテナを起動してみます。
IBM Cloud CLIからIBM Cloudにログインする操作が無いこと、IBM Cloud Shellのロケーションとして「us-south」を指定する必要があることが大きな違いです。

IBM Cloud Shell

IBM Cloud Shellとは？

Webブラウザ上で、bashシェルを実行できる環境です。IBM Cloud上で利用することができます。公式のオンラインマニュアル「IBM Cloud Shellに関するFAQ」によれば、シェルの実行環境は、Ubuntu Linuxとあります。

2020年10月現在、IBM Cloud Shellで使われているUbuntuのバージョンは、18.04.5 LTS (Bionic Beaver)となっています。
確認方法は、IBM Cloud Shellで次のコマンドを実行してみてください。

$ cat /etc/os-release

IBM Cloud Shellのアクセス方法

ChromeなどのWebブラウザでIBM Cloudにログイン後、画面右上の「IBM Cloud シェル」のアイコンをクリックしてください。
image.png

ロケーション変更

2020年10月現在、ここで使用する「IBM Cloud Code Engine」は、IBM Cloudのロケーションとして「ダラス」のみになっていますので、IBM Cloud Shellのロケーションを「us-south」に変更します。

IBM Cloud Shellの画面上部で「変更」をクリックします。
image.png

「Cloud Shellロケーションを変更します」と表示されるので、ロケーションを「ダラス(us-south)」に変更し、「続行」をクリックします。
image.png

IBM Cloud Shellの画面上部で、ロケーションが「ダラス」に変わります。
image.png

Code Engine pluginの有無を確認

IBM Cloud Shellで、Code-Engine用のコマンドを呼び出せるか確認します。

$ ibmcloud plugin show code-engine

下図のように表示されればOKです。IBM Cloud Shellで、2020年10月現在ベータ版のIBM Cloud Code Engineを使用できることがわかります。
image.png

IBM Cloud Code Engineでサーバーレスでコンテナを使う

リソース・グループを指定

リソース・グループ自体の解説については公式のオンラインマニュアルへ。
リソース・グループを指定していない場合は、IBM Cloud Code Engineで、アプリケーションやジョブをまとめる器となる「プロジェクト」を作成することができません。

次のコマンドを実行し、既存のリソース・グループを表示します。

$ ibmcloud resource groups

結果の例

名前      ID                  デフォルト・グループ   状態
default   xxxxxxxxxxxxxxxxx   true                ACTIVE

ここでは名前が「default」というリソース・グループをターゲットに指定します。

$ ibmcloud target -g default

プロジェクト作成

IBM Cloud Code Engineでは、アプリケーションやジョブなどを動かすための器を「プロジェクト」と言い、必ず用意しなければいけません。
次のコマンドを実行します。作成するプロジェクト名は、2ndproject としました。プロジェクト名は英数字が使えますので、好みの名称で良いでしょう。

$ ibmcloud ce project create --name 2ndproject

作成済みの既存のプロジェクトは、次のコマンドを実行することで確認できます。

$ ibmcloud ce project list

実行結果の例

Name        ID                                    Status  Tags  Location  Resource Group  Time to deletion  
2ndproject  ab70ec5f-3fb4-4272-88c6-78dc63024173  active        us-south  default         7 days from now

2020年10月現在、IBM Cloud Code Engineはベータ版のため、7日後に自動削除する旨が表示されます。

プロジェクトの指定

プリケーションを作成するにあたり、プロジェクトを指定するため、次のコマンドを実行します。ここでは作成した2ndprojectを指定しています。実際は、2ndprojectのところがプロジェクト名を指定する箇所になりますので、各自が作成したプロジェクト名に置き換えてコマンドを実行してください。

$ ibmcloud ce project select -n 2ndproject

実行結果の例

Selecting project '2ndproject'...
OK

アプリケーションの作成

DockerHubで公開されているNginxのDockerイメージを呼び出して、IBM Cloud Code Engineにアプリケーションとして作成します。
次のコマンドを実行します。

$ ibmcloud ce application create --name nodered --image nodered/node-red --cpu 1 --memory 512Mi

ここでは、Node-REDのコンテナに、1CPUと512MBのメモリを割り当てています。
実行結果の例

Project '2ndproject' and all its contents will be automatically deleted 7 days from now.
Creating application 'nodered'...
The Configuration is still working to reflect the latest desired specification.
The Route is still working to reflect the latest desired specification.
Configuration 'nodered' is waiting for a Revision to become ready.
Configuration 'nodered' is waiting for a Revision to become ready.
Ingress has not yet been reconciled.
Waiting for load balancer to be ready
Run 'ibmcloud ce application get -n nodered' to check the application status.
OK

https://nodered.ab70ec5f-3fb4.us-south.codeengine.appdomain.cloud

上記のURLにアクセスすることで、作成したアプリケーションにアクセスすることができます。noderedは、ibmcloud ce application create で指定したアプリケーション名で、ab70ec5f-3fb4はアプリケーションが所属するプロジェクトのIDの一部になりますので、各自で異なります。
なお、2020年10月現在、IBM Cloud Code Engineはベータ版のため、7日間で自動削除する旨が表示されています。

アプリケーションのステータス確認

$ ibmcloud ce application get -n nodered

上記のnoderedは、ibmcloud ce application create で指定したアプリケーション名になります。アプリケーション名が異なる場合は、各自が使用したアプリケーション名に置き換えてコマンドを実行してください。

実行結果の例

Name:          nodered  
ID:            ed33006e-da81-4030-b7d6-98d7265da9ab  
Project Name:  2ndproject  
Project ID:    ab70ec5f-3fb4-4272-88c6-78dc63024173  
Age:           5m9s  
Created:       2020-10-06 13:12:37 +0000 UTC  
URL:           https://nodered.ab70ec5f-3fb4.us-south.codeengine.appdomain.cloud  
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/ab70ec5f-3fb4-4272-88c6-78dc63024173/application/nodered/configuration  

Image:  nodered/node-red  
Resource Allocation:  
  CPU:     1  
  Memory:  512Mi  

Revisions:  
  nodered-arbhb-1:  
    Age:                5m8s  
    Traffic:            100%  
    Image:              nodered/node-red (pinned to 7903d6)  
    Running Instances:  0  

Runtime:  
  Concurrency:         10  
  Concurrency Target:  10  
  Maximum Scale:       10  
  Minimum Scale:       0  
  Timeout:             300  

Conditions:  
  Type                 OK    Age    Reason  
  ConfigurationsReady  true  4m39s    
  Ready                true  4m32s    
  RoutesReady          true  4m32s

実行結果として表示されたもののうち、「URL」にアクセスするとアプリケーションが表示され、「Console URL」にアクセスすると、Webブラウザ上で作成したアプリケーションの設定を確認することができます。

「Console URL」にアクセスした例
image.png

Webブラウザからアクセス

アプリケーションの作成、またはアプリケーションのステータス確認で表示されたURLにアクセスし、アプリケーションが動いているか確認します。ここではNode-REDを指定していましたので、Node-REDが表示されます。
image.png

この通り、Node-REDは初期状態です。

実用的な使い方

サーバーレスとしてコンテナを起動できますので、何もアクセスがなければインスタンス(起動中のコンテナ)が自動で削除されますし、アクセスが増えればインスタンスが増えます。上記のようにNode-REDを起動しても、インスタンスが自動で増減するため、IBM Cloud Code Engine上でNode-REDを起動し、フローを設定しても、すぐに初期状態に戻ってしまいます。

従って、手元のPCなどでNode-REDで動かしたいフローを作りこんでおき、コンテナイメージ作成、作成したコンテナイメージを、IBM Cloud Code Engineで動かすことが実用的な使い方と言えます。

その他

コンテナで起動しているアプリケーションのログを見るなどは、IBM Cloud CLIの場合と同じように操作し、確認することができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T22:00:41+09:00

よく使うDockerコマンドまとめ 

#コンテナ一覧
docker ps -a

#実行中のコンテナのみ表示させる
docker container ls

#すべてのコンテナを表示させる
docker container ls -a

#コンテナを削除
docker rm <CONTAINER ID>

#イメージ一覧
docker images

#イメージを削除
docker rmi <IMAGE ID>

#イメージの取得
docker pull hoge

#コンテナに接続
docker run -it hoge bin/sh

#コンテナを停止
docker stop <CONTAINER ID>

#コンテナを再起動
docker restart <CONTAINER ID>

#Docker Composeについて
#バックグランドで実行
docker-compose up -d

#サービスを停止
docker-compose stop

#サービスを開始
docker-compose start

#サービスの停止および破棄
docker-compose down

#「--rm」オプション：コンテナが停止したら自動的に削除
docker run --rm openjdk:9 java --version

#「--workdir」オプション：作業ディレクトリを指定
docker run --rm --mount type=bind,src=/home/hoge/docker,dst=/home/test --workdir /home/test openjdk:9 java Hello

#ネットワークについて
#ネットワーク一覧
docker network ls

#ネットワークを作成
docker network create hoge

#作成したネットワークへコンテナを参加させる
docker run --name nginx --network=hoge -d nginx

#ネットワークを確認
docker network inspect hoge

#ネットワークを削除
docker network rm hoge

#Volumeについて
#Volume一覧
docker volume ls

#Volume詳細
docker volume inspect <Volume ID>

#コンテナを更新してイメージへコミット
docker run -t -i hoge /bin/bash  #コンテナに接続
gem install json                 #コンテナ変更
docker commit -m "Added json gem" -a "Kate Smith" \
<Container ID> <image ID>:tag    #変更したコンテナをもとに、imageを作成
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T21:12:03+09:00

【Go + Gin】Docker環境を構築してみた

はじめに

GoとGinを使用する際のDokcerを用いた開発環境を構築しました。docker-composeを使用しています。
使用するDBはmysqlで、ORマッパーはGormの使用を想定しています。

TL;DR

下記のディレクトリ構成にしています。
Dockerfile、docker-compose.ymlにしています。

ディレクトリ構成

├── docker
│   ├── docker.mysql.env
│   └── go
│       └── Dockerfile
├── docker-compose.yml
└── src
    └── app

docker/go/Dockerfile

FROM golang:1.10.3-alpine3.8

COPY src/app /go/src/app/

WORKDIR /go/src/app/

RUN apk update \
  && apk add --no-cache git \
  && go get github.com/gin-gonic/gin \
  && go get github.com/jinzhu/gorm \
  && go get github.com/go-sql-driver/mysql

EXPOSE 8080

docker/docker.mysql.env

MYSQL_ROOT_PASSWORD=root
MYSQL_DATABASE=go-gin-app
MYSQL_USER=root
MYSQL_PASSWORD=password

docker-compose.yml


services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: ./docker/go/Dockerfile
    ports:
      - 3000:3000
    links:
      - database
    tty:
      true
    volumes:
      - ./src/app:/go/src/app

  database:
    restart: always
    image: mysql:5.7
    ports:
      - 3308:3306
    volumes:
      - mysql-datavolume:/var/lib/mysql
    env_file:
      - docker/docker.mysql.env

volumes:
  mysql-datavolume:
    driver: local

解説

Dockerfile

今回はGoのDockerfileのみを作成し、mysqlはベースイメージを使用するようにdocker-compose.ymlで指定します。

FROM golang:1.10.3-alpine3.8

COPY src/app /go/src/app/

WORKDIR /go/src/app/

RUN apk update \
  && apk add --no-cache git \
  && go get github.com/gin-gonic/gin \
  && go get github.com/jinzhu/gorm \
  && go get github.com/go-sql-driver/mysql

EXPOSE 8080

src/app直下のファイルをボリュームに指定しています。

また、aliphineのベースイメージを指定しているので、apkでGin、Gorm関連のパッケージをインストールしています。

docker-compose.yml

services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: ./docker/go/Dockerfile
    ports:
      - 3000:3000
    links:
      - database
    tty:
      true
    volumes:
      - ./src/app:/go/src/app

  database:
    restart: always
    image: mysql:5.7
    ports:
      - 3307:3306
    volumes:
      - mysql-datavolume:/var/lib/mysql
    env_file:
      - docker/docker.mysql.env

volumes:
  mysql-datavolume:
    driver: local

mysqlのenvファイルを別で作成したので、env_fileで指定します。
ポート 3306はローカルのmysqlでよく使用するので、3307を指定しています。

動作確認

src/app直下にmain.goを作成し、おなじみのhello worldを出力するようにコードを記述します。

package main

import "fmt"

func main() {
        fmt.Println("Hello, world")
}

そして、下記コマンドでhello worldを出力させます。

docker-compose exec app go run main.go

hello worldが出力されたでしょうか。

終わりに

意外と簡単にGo+Ginの環境構築を行うことができました。

やはりDockerを使用すると環境構築が楽になりますね、！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T18:39:39+09:00

AWS Chaliceの開発環境をdockerで構築し、超高速でサーバーレスアプリケーションをデプロイしてみた

AWS Chaliceの開発環境をdockerで構築し、超高速でサーバーレスアプリケーションをデプロイしてみた

ChaliceもLambdaも初めてですが、
初めてのサーバーレスアプリケーションに興奮したので書きます

ソースコード naokit-dev/python3_chalice_on_docker

Chalice (チャリス?)

AWSが提供するPythonフレームワーク
Lambdaを使ったサーバーレスアプリケーションを簡単にデプロイできる
Documentation — AWS Chalice

環境

  • macOS Catalina
  • VS Code
  • Docker Desktop
docker --version
Docker version 19.03.13, build 4484c46d9d
docker-compose --version
docker-compose version 1.27.4, build 40524192

その他、AWSのアクセスキーが必要になります

準備運動

Docker Hubで使用するイメージを確認します
python - Docker Hub

AWS ChaliceはLambdaでサポートされているすべてのpythonが使用できるが3系が推奨とのこと

AWS Chalice supports all versions of python supported by AWS Lambda, which includes python2.7, python3.6, python3.7, python3.8. We recommend you use a version of Python 3.
Quickstart — AWS Chalice

ここでは、3.8-alpineを使用してみます

VS Codeで新規ワークスペースを作成
"python3_chalice_on_docker"としました

(次の手順は必要ないのですが、pythonが動く最小構成として試してみました)

Docker HubのイメージをPullしてコンテナを起動します

  • -it 標準入力にアタッチ
  • --rm コンテナ終了時にコンテナを削除
  • -v : host_pathをボリュームとしてマウント
docker run -it --rm -v $PWD:/python python:3.8-alpine /bin/sh

(-v .:/pythonのように相対パスでマウントしようとするとエラーとなるが、環境変数$PWDが使えるようで-v $PWD:/pythonなら問題ない | Volume相対パス指定でもdocker runがしたい！ - Qiita)

# python --version
Python 3.8.6

Dockerfileを作成

先程作成したワークスペースでの作業になります

Dockerfileを作成
pip install chaliceでchaliceをインストールします

touch Dockerfile

FROM python:3.8-alpine

WORKDIR /app

RUN pip install chalice

CMD [ "/bin/sh"]

つぎにdocker-compose.ymlを作成
ポートマッピング、ボリューム作成のほか、.envに記述した環境変数をコンテナ内で扱えるようにしています

touch docker-compose.yml

version: "3.8"
services:
  app:
    build: .
    ports:
      - "80:8000"
    volumes:
      - .:/app
    command: chalice local --host=0.0.0.0 --port=8000
    tty: true
    stdin_open: true
    working_dir: "${APP_PATH}"
    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}

.envを作成
ここに環境変数を定義します
APP_NAMEはいまはブランクのまま
ほかも今はそのままで構いませんが、AWSにデプロイするために必要なcredentialsを記述することになります

touch .env

APP_NAME=
APP_PATH=/app/${APP_NAME}
AWS_ACCESS_KEY_ID=[YOUR_ACCESS_KEY_ID]
AWS_SECRET_ACCESS_KEY=[YOUR_SECRET_ACCESS_KEY]
AWS_DEFAULT_REGION=ap-northeast-1

端末にAWSのcredentialsが保存されている場合
以下で確認できます

cat ~/.aws/credentials

chalice projectを作成

chalice new-project <project_name>で新規プロジェクトを作成します

docker-compose run app chalice new-project test_chalice

以下のような構成になります

.
├── .env
├── Dockerfile
├── docker-compose.yml
└── test_chalice
    ├── .chalice
    │   └── config.json
    ├── .gitignore
    ├── app.py
    └── requirements.txt

環境変数を定義

.envを編集します
APP_NAMEに先程のプロジェクト名を、AWS_ACCESS_KEY_IDおよびAWS_SECRET_ACCESS_KEYもここに記述します
Regionはap-northeast-1に設定してありますが適宜変更してください

APP_NAME=test_chalice
APP_PATH=/app/${APP_NAME}
AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxx
AWS_DEFAULT_REGION=ap-northeast-1

ローカルサーバーをたてる

ローカルサーバーを起動

docker-compose up

docker-compose.ymlでcommand: chalice local --host=0.0.0.0 --port=8000としてコマンドを上書きしてあるので、docker-compose up時にchalice localが実行されます

ports: - "80:8000"でホスト側のport 80をコンテナ内のport 8000にマッピングしてあるので、ホストからlocalhostにアクセスすると、chaliceのlocal serverにポートフォワーディングされます

curl localhost
{"hello":"world"}%

"hello world"が返ってきました

test_chalice/app.pyをみてみます
以下のコメントアウトされている部分を、コメントアウト解除します

# @app.route('/hello/{name}')
# def hello_name(name):
#    # '/hello/james' -> {"hello": "james"}
#    return {'hello': name}

/hello/chaliceにアクセスしてみると

curl localhost/hello/chalice
{"hello":"chalice"}%

"hello chalice"が返ってきました
RESTfulな挙動が確認できます

ローカルサーバーを停止

docker-compose down

デプロイしてみる

chalice deployでAWS Lambda関数としてデプロイされます

docker-compose run app chalice deploy

Creating deployment package.
Creating IAM role: test_chalice-dev
Creating lambda function: test_chalice-dev
Creating Rest API
Resources deployed:
  - Lambda ARN: arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxx:function:test_chalice-dev
  - Rest API URL: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/api/

Rest API URLにアクセスしてみます

curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/api/
{"hello":"world"}%

curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/api/hello/lambda
{"hello":"lambda"}%

chaliceがコードを解析し、
必要なIAM roleを付与してLambda関数としてデプロイしてくれるそうです

次は少し実用的なアプリに挑戦してみたいと思います

Ref.

Documentation — AWS Chalice

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T18:20:45+09:00

SonarQubeのDockerContainerをUpdateした話

はじめに

SonarQubeをDockerContainerにしてみた話 の SonarQube のその後の話です。

経緯

ある開発のお手伝いをしたのですがオンプレミス環境でかなり古いバージョンの SonarQube を利用していて微妙な状態でした。
個人的に2年近く前にSonarQubeのDockerContainer化をしていたので、最新のバージョンにして提供しましたのでその際の備忘です。

実施したこと

  • SonarQube Ver 7.4 を SonarQube Ver 8.4.2に変更
  • SonarQube用のDBを MySQL から PostgreSQL Ver 13.0 に変更（End of Life of MySQL Support ）
  • docker-composeファイルを Ver 3 に変更

SonarQube Ver 7.4 を SonarQube Ver 8.4.2に変更

利用するContaner Imageを sonarqube:8.4.2-community に変更するだけの簡単な作業です。

  # SonarQube Server
  sonarqube-server:
    container_name: sonarqube-server
    image: sonarqube:8.4.2-community

SonarQube用のDBを MySQL から PostgreSQL Ver 13.0 に変更

End of Life of MySQL Support の通り、最新の SonarQube ではMySQLがサポートされないためPostgreSQLに乗り換えます。

利用するContaner Imageを postgres:13.0-alpine に変更し、公式ガイドを参考に volumes と environment を変更します。
合わせてcontainer_nameなどもわかりやすいものに変更します。

  # SonarQube Server用Database
  postgres-sonarqube:
    container_name: postgres-sonarqube
    image: postgres:13.0-alpine
    volumes:
      - "./data/postgresql/init:/docker-entrypoint-initdb.d"
      - "./data/postgresql/db:/var/lib/postgresql"
    ports:
      - "5432:5432"
    networks:
      - sonarqube-server-network
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
      - POSTGRES_DB=sonar

また、 SonarQube ContanerのDB接続情報(environment)も変更します。

  # SonarQube Server
  sonarqube-server:
    container_name: sonarqube-server
    image: sonarqube:8.4.2-community
    command: -Dsonar.web.context=/sonarqube
    links:
      - postgres-sonarqube:postgres
    volumes:
      - ./data/sonarqube/extensions/plugin:/opt/sonarqube/extensions/plugins
    ports:
      - "9000:9000"
      - "9092:9092"
    networks:
      - sonarqube-server-network
    environment:
      - SONARQUBE_JDBC_USERNAME=sonar
      - SONARQUBE_JDBC_PASSWORD=sonar
      - "SONARQUBE_JDBC_URL=jdbc:postgresql://postgres-sonarqube:5432/sonar"

docker-composeファイルを Ver 3 に変更

今はVer3が主流なので、docker-composeファイルのversionsも 3 に変更します。

version: '3'
services:

動作確認

ここまで対応したら、以下のコマンドで動作確認をして作業終了です。

docker-compose up --force-recreate sonarqube-server

感想

データ移行は考慮しないバージョンアップ作業が主なので簡単でした。
改めてDocker Container化しておくとこの辺は簡単で良いと感じました。
これでしばらくは頑張れそうですね。

本記事の対応は以下のgithubリポジトリに公開していますので興味ありましたら参考にしてください。
https://github.com/awakuwaku/sonar-qube-docker

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T17:05:25+09:00

初学者によるDocker理解まとめ①　〜docker run -pまで〜

　はじめに

ようやくDockerを学びだしたので自分の理解をまとめておく。

*　Dockerによるコンテナ化によるマイクロサービスの実現
*　docker run -p のpはportのp

　今日の学びをメモ

スクリーンショット 2020-10-06 16.46.52.png

スクリーンショット 2020-10-06 16.53.41.png

スクリーンショット 2020-10-06 17.02.39.png

スクリーンショット 2020-10-07 8.08.25.png

スクリーンショット 2020-10-06 17.04.07.png

　まとめ

Dockerを使って処理ごとにホストを分けてデプロイする。疎結合でシステムの信頼性が上がる。
これを理解すれば念願のFargateの世界へ。もうLambdaは卒業できるはず。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T12:07:16+09:00

[Docker] コンテナの起動を少しでも早くする

環境情報

Docker Engine v18.09
メモリを20GB程度積んだRHEL7

コンテナが使うファイルシステム

dockerの関連ファイル群は/var/lib/dockerに入っており、特に指定していなければデフォルトのファイルシステムにて動いています。

# df /var/lib/docker
..
/dev/mapper/rhel-var ... /var

よってローカルにイメージをため込みすぎると以下が逼迫するというのはよく聞く話です。

/var/lib/docker/overlay2/

コンテナの起動は連続すると早くなる

意外と知られていない事実に、コンテナを連続して起動すると二回目は少し早くなります。

これはDockerイメージがディスク上に保管されているのかメモリのキャッシュに残っているのかの差です。それを実感したい方は

time docker run ubuntu echo "hello"

といったようなコンテナを起動してhelloを標準出力するだけのコマンドを連続して叩いてみてください。少し早くなっているはずです。

ちなみに私が遊んでいる環境だと0.8sが0.6sになる程度なので誤差ですが、ここが明確に変化する場合は下記の対応はおススメです。

/var/lib/dockerをRAMディスクにする

RAMディスクの説明や作り方は割愛しますが、dockerを停止→/var/lib/dockerを丸ごと別名でコピー→新たなファイルシステムとして/var/lib/dockerを用意→コピーしたファイル群を展開→dockerを起動　すると常にキャッシュにのっているスピードで起動されます。

ただし、メモリにのっている都合上再起動するたびに消えてしまうので、例えばイメージをローカルに置いている場合はそこの手当ては必要です。あと、やるのであればメモリが潤沢にある環境でやらないと結果的にシステム全体がSwap起こしたりするので注意してください。

まとめ

Docker関連のファイルをすべてメモリに乗せることで、コンテナ環境の動作を早くさせることができます。また、本質としてはイメージがディスクにのっているのかメモリにのっているのかによって変わる起動時間の揺れを防ぐことが可能になります。連続して起動した際に大きな時間差がある場合、この揺れを無くしている設計は起動失敗判定に時間を使うのであれば重要です。

以上。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T11:09:43+09:00

同一リポジトリでNuxt.js(Frontend) + Laravel(API)な開発環境を準備する

概要

LaravelのBlade運用にツラさを感じてきてフロントを分離したくなったので調査して開発環境を準備した。
同一リポジトリにした理由はフロント側の開発をしている時に同一の方がAPIの検証をしやすいと思ったからです。
調査ついでに記事として残しておく。

環境

  • Host:Mac
  • Docker
    • nginx:1.19-alpine
    • node:13.8-alpine
    • php:7.4-fpm-alpine

完成イメージ

spa_dev_template.png

完成品

https://github.com/nagi125/spa_dev_template
※ NuxtとLaravelのプロジェクトはREADME.mdを見て生成してください。

ざっくり説明

Laravelのプロジェクト内に「frontend」というディレクトリを準備をし、Nuxtのプロジェクト一式はそちらに準備します。
volume機能を用いてNuxt側とLaravel側で、各種ファイルを共有しています。
そしてNuxt側はデフォルト位置を「/app/frontend」に、Laravel側はデフォルト位置を「/app」にしておけば完成です。

各コンテナについて

Nginx

FROM nginx:1.19-alpine

ENV TZ Asia/Tokyo

COPY conf/default.conf /etc/nginx/conf.d/default.conf

Nginxのconfファイル

server {
    server_name         localhost;
    root  /app/public;
    index index.php;

    proxy_set_header    Host                 $host;
    proxy_set_header    X-Real-IP            $remote_addr;
    proxy_set_header    X-Forwarded-Host     $host;
    proxy_set_header    X-Forwarded-Server   $host;
    proxy_set_header    X-Forwarded-For      $proxy_add_x_forwarded_for;

    location / {
        proxy_pass    http://frontend:3000;
    }

    location /api {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass   api:9000;
        fastcgi_index  index.php;

        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param  PATH_INFO $fastcgi_path_info;
    }
}

開発環境なので若干雑に作っている部分はあります。
/apiの場合はLaravelを見にいき、デフォルトはNuxtを見にいくようにRP設定してあります。
※FastCGIの場合は厳密にはRPと言わないかもしれませんが・・・。

Nuxt.js

FROM node:13.8-alpine

RUN apk update && \
    apk add git && \
    apk add --no-cache curl && \
    curl -o- -L https://yarnpkg.com/install.sh | sh && \
    yarn add @vue/cli @vue/cli-service-global nuxt create-nuxt-app

ENV TZ Asia/Tokyo
ENV PATH $HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH

WORKDIR /app/frontend

CMD ["/bin/ash"]

npmではなくyarn派なのでyarnを利用するように調整してあります。
ポイントは作業領域を「/app/frontend」にしておくところです。

Laravel

FROM php:7.4-fpm-alpine

ENV TZ Asia/Tokyo
ENV COMPOSER_ALLOW_SUPERUSER 1

# install Lib
RUN apk update && \
    apk add --no-cache --virtual .php-builds oniguruma-dev git zip unzip

# add php-ext-module
RUN docker-php-ext-install mbstring && \
    docker-php-ext-enable mbstring

# install Composer
RUN curl -sS https://getcomposer.org/installer | php && \
    mv composer.phar /usr/local/bin/composer && \
    chmod +x /usr/local/bin/composer

WORKDIR /app

こちらのコンテナは作業領域を「/app」にしておきます。

docker-compose

version: '3'
services:
  nginx:
    container_name: nginx
    build:
      context: ./docker/nginx
      dockerfile: Dockerfile
    ports:
      - 80:80
    tty: true
    depends_on:
      - frontend

  frontend:
    container_name: frontend
    build:
      context: ./docker/frontend
      dockerfile: Dockerfile
    environment:
      PORT: '3000'
      HOST: '0.0.0.0'
      API_URL: 'http://localhost/api/v1'
    expose:
      - 3000
    volumes:
      - .:/app
    stdin_open: true
    tty: true
    restart: always
    depends_on:
      - api

  api:
    container_name: api
    build:
      context: ./docker/api
      dockerfile: Dockerfile
    environment:
      LANG: 'ja_JP.UTF-8'
      TZ: 'Asia/Tokyo'
    volumes:
      - .:/app
    expose:
      - 9000
    tty: true
    restart: always

docker-composeではNuxtとLaravelのコンテナの「/app」をホストと共有します。
DBを追加したい場合はdocker-composeに書き足せばよいでしょう。

起動

上記まで準備できたら下記コマンドで開発環境が立ち上がるはずです。

$ docker-compose build
$ docker-compise up

NuxtとLaravelプロジェクトの作成

Nuxt

下記コマンドでNuxtプロジェクトの作成をします。
質問の答えについてはここでは省略します。
お好みの設定にしてください。

$ docker-compose exec frontend yarn create nuxt-app ./

下記コマンドで開発モードの立ち上げをします。

$ docker-compose exec frontend yarn dev

Laravel

下記コマンドでLaravelプロジェクトの作成をします。
バージョンはお好みの物にしてください。
※ 直下を指定するとファイルが存在しておりプロジェクト作成不可能と怒られますので一旦「blog」として作ります。

$ docker-compose exec api composer create-project --prefer-dist laravel/laravel blog "6.*"

「blog」ディレクトリの内容を直下にコピーします。

$ docker-compose exec api cp -fR ./blog/. ./

「blog」ディレクトリの削除

$ docker-compose exec api rm -rf ./blog

完成

NuxtとLaravelのプロジェクトの生成が完了すれば開発環境として利用できるようになります。
Nuxt側には「localhost」で、Laravel側には「localhost/api」でアクセスできます。
※Laravel側のroute設定を忘れずに。

本番運用は？

開発用のDockerfileなのでECSとかを利用する場合はこちらはDockerfile.devとして、本番用のDockerfileを準備してください。
Heroku + Netlifyの場合はこのリポジトリをそのままPushすればそのまま使えます。
※Heroku側とNetlify側でpush検知の設定をしてください。

最後に

調査内容のメモとなりますが、何かのお役に立てれば幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T11:09:43+09:00

docker-composeを利用して同一リポジトリでNuxt.js(Frontend) + Laravel(API)な開発環境を準備する

概要

LaravelのBlade運用にツラさを感じてきてフロントを分離したくなったので調査して開発環境を準備した。
同一リポジトリにした理由はフロント側の開発をしている時に同一の方がAPIの検証をしやすいと思ったからです。
調査ついでに記事として残しておく。

環境

  • Host:Mac
  • Docker
    • nginx:1.19-alpine
    • node:13.8-alpine
    • php:7.4-fpm-alpine

完成イメージ

spa_dev_template.png

完成品

https://github.com/nagi125/spa_dev_template
※ NuxtとLaravelのプロジェクトはREADME.mdを見て生成してください。

ざっくり説明

Laravelのプロジェクト内に「frontend」というディレクトリを準備をし、Nuxtのプロジェクト一式はそちらに準備します。
dockerのvolume機能を用いてNuxt側とLaravel側で、各種ファイルを共有しています。
そしてNuxt側はデフォルト位置を「/app/frontend」に、Laravel側はデフォルト位置を「/app」にしておけば完成です。

各コンテナについて

Nginx

FROM nginx:1.19-alpine

ENV TZ Asia/Tokyo

COPY conf/default.conf /etc/nginx/conf.d/default.conf

Nginxのconfファイル

server {
    server_name         localhost;
    root  /app/public;
    index index.php;

    proxy_set_header    Host                 $host;
    proxy_set_header    X-Real-IP            $remote_addr;
    proxy_set_header    X-Forwarded-Host     $host;
    proxy_set_header    X-Forwarded-Server   $host;
    proxy_set_header    X-Forwarded-For      $proxy_add_x_forwarded_for;

    location / {
        proxy_pass    http://frontend:3000;
    }

    location /api {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass   api:9000;
        fastcgi_index  index.php;

        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param  PATH_INFO $fastcgi_path_info;
    }
}

開発環境なので若干雑に作っている部分はあります。
/apiの場合はLaravelを見にいき、デフォルトはNuxtを見にいくようにRP設定してあります。
※FastCGIの場合は厳密にはRPと言わないかもしれませんが・・・。

Nuxt.js

FROM node:13.8-alpine

RUN apk update && \
    apk add git && \
    apk add --no-cache curl && \
    curl -o- -L https://yarnpkg.com/install.sh | sh && \
    yarn add @vue/cli @vue/cli-service-global nuxt create-nuxt-app

ENV TZ Asia/Tokyo
ENV PATH $HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH

WORKDIR /app/frontend

CMD ["/bin/ash"]

npmではなくyarn派なのでyarnを利用するように調整してあります。
ポイントは作業領域を「/app/frontend」にしておくところです。

Laravel

FROM php:7.4-fpm-alpine

ENV TZ Asia/Tokyo
ENV COMPOSER_ALLOW_SUPERUSER 1

# install Lib
RUN apk update && \
    apk add --no-cache --virtual .php-builds oniguruma-dev git zip unzip

# add php-ext-module
RUN docker-php-ext-install mbstring && \
    docker-php-ext-enable mbstring

# install Composer
RUN curl -sS https://getcomposer.org/installer | php && \
    mv composer.phar /usr/local/bin/composer && \
    chmod +x /usr/local/bin/composer

WORKDIR /app

こちらのコンテナは作業領域を「/app」にしておきます。

docker-compose

version: '3'
services:
  nginx:
    container_name: nginx
    build:
      context: ./docker/nginx
      dockerfile: Dockerfile
    ports:
      - 80:80
    tty: true
    depends_on:
      - frontend

  frontend:
    container_name: frontend
    build:
      context: ./docker/frontend
      dockerfile: Dockerfile
    environment:
      PORT: '3000'
      HOST: '0.0.0.0'
      API_URL: 'http://localhost/api/v1'
    expose:
      - 3000
    volumes:
      - .:/app
    stdin_open: true
    tty: true
    restart: always
    depends_on:
      - api

  api:
    container_name: api
    build:
      context: ./docker/api
      dockerfile: Dockerfile
    environment:
      LANG: 'ja_JP.UTF-8'
      TZ: 'Asia/Tokyo'
    volumes:
      - .:/app
    expose:
      - 9000
    tty: true
    restart: always

docker-composeではNuxtとLaravelのコンテナの「/app」をホストと共有します。
DBを追加したい場合はdocker-composeに書き足せばよいでしょう。

起動

上記まで準備できたら下記コマンドで開発環境が立ち上がるはずです。

$ docker-compose build
$ docker-compise up

NuxtとLaravelプロジェクトの作成

Nuxt

下記コマンドでNuxtプロジェクトの作成をします。
質問の答えについてはここでは省略します。
お好みの設定にしてください。

$ docker-compose exec frontend yarn create nuxt-app ./

下記コマンドで開発モードの立ち上げをします。

$ docker-compose exec frontend yarn dev

Laravel

下記コマンドでLaravelプロジェクトの作成をします。
バージョンはお好みの物にしてください。
※ 直下を指定するとファイルが存在しておりプロジェクト作成不可能と怒られますので一旦「blog」として作ります。

$ docker-compose exec api composer create-project --prefer-dist laravel/laravel blog "6.*"

「blog」ディレクトリの内容を直下にコピーします。

$ docker-compose exec api cp -fR ./blog/. ./

「blog」ディレクトリの削除

$ docker-compose exec api rm -rf ./blog

完成

NuxtとLaravelのプロジェクトの生成が完了すれば開発環境として利用できるようになります。
Nuxt側には「localhost」で、Laravel側には「localhost/api」でアクセスできます。
※Laravel側のroute設定を忘れずに。

本番運用は？

開発用のDockerfileなのでECSとかを利用する場合はこちらはDockerfile.devとして、本番用のDockerfileを準備してください。
Heroku + Netlifyの場合はこのリポジトリをそのままPushすればそのまま使えます。
※Heroku側とNetlify側でpush検知の設定をしてください。

最後に

調査内容のメモとなりますが、何かのお役に立てれば幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T10:22:31+09:00

Django×Postgresql on DockerをHerokuへデプロイしたメモ

はじめに

DjangoGirlsなどのチュートリアルで作成したDjangoアプリをDocker化した。そしてアプリをHerokuへデプロイしたい。チュートリアルでもHerokuのデプロイ方法は載っているので基本的にそれを参考にすればデプロイできる。分からなくなったら1,2度はローカルで環境構築、開発、デプロイをしてみると良いかもしれない

前提

herokuについての知識がある

手順

  1. Pythonライブラリのリストにherokuへ必要なパッケージを追加編集し、保存
requirements.txt
Django==2.2.16
psycopg2

# この下が新たに追加するライブラリ
dj-database-url
gunicorn
whitenoise==3.0.0

2.ルートディレクトリにProcfileを作成し、編集、保存

Procfile
web: gunicorn 管理インターフェース名.wsgi --log-file -

3.どのバージョンのPythonを使いたいのかをHerokuに知らせるため。

runtime.txt
python-3.6.4

4.開発環境ファイルを作成し、編集保存する
今回は開発環境でもpostgresqlなので、DATABASEの欄は自身のsettings.pyのデータベース設定をコピーする。
以下はサンプル。

管理インターフェース/local_settings.py
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': 'postgres',
        'HOST': 'db',
        'PORT': 5432,
    }
}

DEBUG = True

5.本番環境のため設定ファイルを編集する
こちらもデータベースの設定は各自の環境を設定

管理インターフェース/settings.py
import dj_database_url

...

DEBUG = False

ALLOWED_HOSTS = ['127.0.0.1', '.herokuapp.com']

...

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'postgres',
        'USER': 'postgres',
        'PASSWORD': 'postgres',
        'HOST': 'db',
        'PORT': '5432',
    }
}

...

db_from_env = dj_database_url.config(conn_max_age=500)
DATABASES['default'].update(db_from_env)

6.wsgi.pyを編集する

管理インターフェース/wsgi.py
...
# Heroku
from whitenoise.django import DjangoWhiteNoise
application = DjangoWhiteNoise(application)

7.herokuへデプロイする
herokuへのデプロイは大きくわけてコマンドラインから直接pushするか、Githubのコードを自動デプロイできます。どちらかの方法でherokuへコードをupします。

8.本番環境(heroku)のデータベースを設定する
herokuのサーバ上でマイグレーションを実行し、管理者ユーザーを作成します
こちらもコマンドラインとherokuのサイトから操作することも可能です

9.デプロイ成功
URLからきちんとデプロイできているか確認する

参考文献

https://tutorial-extensions.djangogirls.org/ja/heroku/
https://devcenter.heroku.com/articles/getting-started-with-python

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T02:27:29+09:00

Docker（Windows）のUbuntuコンテナでNordVPNを動かす

こんな人向け

  • 複数コンテナで別々のIPを取得したい
  • 格安で

手順

  1. Dockerインストール
  2. コンテナ立ち上げ
  3. 起動イメージ作成
  4. NordVPN接続
  5. その他コマンド

1.Dockerインストール

ダウンロード（dockerhub）：
https://hub.docker.com/editions/community/docker-ce-desktop-windows/
参考手順サイト：
https://ops.jig-saw.com/tech-cate/docker-for-windows-install

2.コンテナ立ち上げ

docker pull ubuntu
docker run -it --name ubuntu1 ubuntu bash

3.起動イメージ作成

NordVPNインストール

apt-get update
apt-get install wget
wget -qnc https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/nordvpn-release_1.0.0_all.deb
apt install -y nordvpn-release_1.0.0_all.deb

エラーが出るので、

ERROR
E: Unable to locate package nordvpn

apt installとupdateとupgradeを何回か繰り返してると通る。

apt update
apt upgrade
apt install -y nordvpn

エラーで進めなかったら必要に応じて、

apt --fix-broken install

も混ぜて叩いてみる。

この時点では、以下の追加設定が必要なため、一時イメージを作成する。

  • nordvpndがsystemdにより実行されていること（bash等から起動していないこと）
  • コンテナにネットワークデバイスの使用権限を付与すること

一時イメージ作成

コンテナからexitしておく。

docker commit ubuntu1 ubuntu-nordvpn

Dockerfile作成

コンテナ立ち上げ時に、nordvpnが起動するようにする。
公式：NordVPN Dockerイメージを構築する方法は？

Dockerfile
FROM ubuntu-nordvpn

ENTRYPOINT ["/usr/sbin/nordvpnd", "&"]

ビルドする

Dockerfileがあるディレクトリで、以下のコマンドを実行する。
最後にカレントディレクトリのDockerfileを参照する「．（ピリオド）」を付ける。

docker build -t ubuntu-nordvpn-entrypoint .

新イメージからコンテナ立ち上げ

コンテナにネットワークデバイスの使用権限を付与するオプションを付けて起動する。

docker run -it --cap-add=NET_ADMIN --cap-add=SYS_MODULE --device /dev/net/tun --name ubuntu-nordvpn-entrypoint1 --sysctl net.ipv4.conf.all.rp_filter=2 ubuntu-nordvpn-entrypoint

シェルの反応が返ってこなかったら、Ctrl+p Ctrl+q で一度、コンテナから抜ける。再度、bashで入る。

docker exec -it ubuntu-nordvpn_entrypoint1 bash

4.NordVPN接続

nordvpn login
# Username : NordVPNアカウント登録時のメールアドレス
# Password : NordVPNアカウント登録時のログインパスワード
nordvpn set protocol tcp
nordvpn set killswitch on     #エラーが出てもon登録される
nordvpn connect Japan

5.その他コマンド

IPチェック用

wget -O - http://inet-ip.info/

リンク

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-06T00:22:15+09:00

Dokcer環境等で発生するSelenium::WebDriver::Error::UnknownErrorの対処法

Dokcer環境などのCUI環境でcapybara/selenium/chromedriverを利用する際は no-sandbox/disable-dev-shm-usageオプションが必要

Selenium::WebDriver::Error::UnknownError:
                unknown error: Chrome failed to start: exited abnormally.
                  (unknown error: DevToolsActivePort file doesn't exist)
                  (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
capybara.rb
...
Capybara.register_driver :selenium_chrome_headless do |app|
  options = ::Selenium::WebDriver::Chrome::Options.new
  options.add_argument('--headless') 
  options.add_argument('--no-sandbox') # chrootで隔離された環境(Sandbox)での動作を無効
  options.add_argument('--disable-dev-shm-usage') # 共有メモリファイルの場所を/dev/shmから/tmpに移動
  options.add_argument('--disable-gpu')
  options.add_argument('--window-size=2500,2500')
  Capybara::Selenium::Driver.new(app, browser: :chrome, options: options)
end

Capybara.javascript_driver = :selenium_chrome_headless
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧