20200515のdockerに関する記事は17件です。

Dockerコンテナ(Ubuntu)でOpenCVのimshowが表示されないときの対処法

はじめに

筆者はQiita初投稿である。
Qiitaの書き方について「もっとこうした方がいいよ!」などコメント頂けると幸いである。

経緯と問題

経緯

機械学習の勉強として、かめ@米国データサイエンティストさんの記事を参考にし、Dockerコンテナ上(Ubuntu)でJupyter Labを使用できるようにした(参照1)。また、追加でOpenCVをインストール&インポートを行った(参照2)。

(参照1)DockerでJupyter Labを使う
(参照2)OpenCVによる画像の読み込みと色空間の変換,表示

問題

OpenCVをいろいろ勉強しようと思い、参照1・参照2で構築したUbuntu上のJupyter LabでOpenCVのimshowで画像を表示しようとするとKernel Restartingとなり表示されない。

ccead6dfde6d928a2da9a8413e5e99eb.png

その際にTerminal上で表示されたJupyter Labのログ?は以下の通りある。
cannot connect to X server ? なんじゃそりゃ?

[I 12:38:37.627 LabApp] Kernel started: a79b264a-3b96-463d-83d6-64904b98938a
: cannot connect to X server
[I 12:38:46.627 LabApp] KernelRestarter: restarting kernel (1/5), keep random ports
kernel a79b264a-3b96-463d-83d6-64904b98938a restarted

また、そのとき実行したコードはこちらである。

import cv2
import os

img = cv2.imread("src/Berry.jpg")

cv2.imshow("img",img)
cv2.waitKey(0)
cv2.destroyAllWindows()

対処法

XQuartzの導入・起動

cannot connect to X serverについて調べてみると、
UNIX系のOSではGUI環境(画像を表示する)を作るのにX Window Systemを利用する必要があるらしい。
XquartzはmacOS用のX Window Systemでそれを導入・起動する。

$ brew cask install xquartz #インストール
$ open -a XQuartz #起動

ちなみにX Window Systemはクライアントサーバ型のシステムで、今回は以下の通りである。
・Xクライアント:macOS上のDockerコンテナ(Ubuntu)
・Xサーバ:macOS

Xサーバへの接続権限を付与

下記のコマンドを実行し、Xサーバへの接続権限を与える。

$ ip=$(ifconfig en0 | grep inet | awk '$1=="inet" {print $2}') #macOSのIPを取得
$ xhost + $ip #接続権限の不可

DISPLAY環境変数、X Windowをオプションで付けてコンテナをRUN

Dockerイメージをbuildしたら下記を実行する。

docker run -p 8888:8888 -e DISPLAY=$ip:0 -e USER=root -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/Desktop/ds_python:/work --name my-lab {イメージID}

ちなみに参照1に記載されているRUNコマンドに以下のオプションを追加したものである。
-vオプション(2つ目)は各自好きなように設定すること。
・-eオプション(1つ目):DISPLAY環境変数の設定、Xサーバへの接続権限を付与したmacOSのIPが入る
・-eオプション(2つ目):コンテナ内のUbuntuユーザをrootに指定
・-vオプション(1つ目):X Windowを接続

#結果
ミッションコンプリート。imshowで画像が表示されるようになりました。
951f8498a6fb6210e502302a5cc01110.jpg

結論

以下をすることでDockerコンテナ(Ubuntu)でOpenCVのimshowを表示することができた。
・XQuartzの導入・起動
・Xサーバへの接続宣言を付与
・DISPLAY環境変数、X Windowをオプションで付けてコンテナをRUN

参考ページ

今回の解決にあたって参考となったページは以下の通りである。
Dockerコンテナの中でGUIアプリケーションを起動させる
Docker for Macで作ったUbuntuコンテナ内のGUIプログラム(spyder)を使う
Dockerを導入してGUI操作可能なLinux(Ubuntu)コンテナを作成する

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

Windows 10 Home で WSL 2 + Docker を使う

今月にアップデートを予定している Windows Version 20H1 (2004) の目玉機能の WSL 2 を使うことで Windows 10 Home でも Docker が使えるようになります。もともと Windows 10 Home では Virtual Box, Windows 10 Pro では Hyper-V などを利用することで Docker を利用することができたのですが、おそらく今後は使いやすくて便利な WSL 2 を利用すること増えるのではないかと考えています。この記事では 20H1 Preview Version を利用して、インストールから実行までをまとめたものになります。もちろん Windows 10 Pro でも、これと同じ手順で問題ないです。

WSL 2

まず最初に WSL 2 をインストールして実行してみます。

Enable Virtualization

WSL 2 を起動するためには CPU の Virtualization が有効化されている必要があります。 Task Manager を開いて Performance > CPU 画面から、 Virtualization: Enabled になっていることを確認します。

もし Enabled になっていない場合は Bios を開いて CPU Configuration > Intel (AMD) Virtualization Technology: Enabled にする必要があります。

Image from Gyazo

Enable Windows Feature

管理者モードで Windows PowerShell or PowerShell 6 を起動して二つのコマンドを実行します。再起動しないと機能が有効にならないため、コマンドを実行後に再起動してください。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
# ?再起動を忘れずに

Install WSL 2 kernel

このページ Updating the WSL 2 Linux kernel | Microsoft Docs を開いて download the latest WSL2 Linux kernel を選択して Installer をダウンロードします。ダウンロードした Installer を実行してください。

今後の予定では Terminal から Install できるようになるとのことです。

Install Ubuntu (Linux OS)

Microsoft Store から Ubuntu-20.04 を Install します。今回は Ubuntu を利用しましたが、 Install Windows Subsystem for Linux (WSL) on Windows 10 | Microsoft Docs に記載されている通り、 Ubuntu ではなく好きな Linux でも問題ないと思います。 Microsoft Store 以外からの Install も可能と書いてありました。

WSL 2 の設定、実行確認

これで WSL 2 を利用する準備が整いました。 PowerShell や Terminal (Command Prompt) を開いて、実際に WSL のコマンドを実行してみます。

デフォルトで WSL 2 を利用するコマンドと、 Install した Ubuntu で WSL 2 を利用するコマンドを実行します。コマンド実行後に wsl -l -v を実行して Ubuntu が WSL 2 で動いていることを確認します。

wsl --set-default-version 2
wsl --set-version Ubuntu-20.04 2

wsl -l -v
#   NAME                   STATE           VERSION
# * Ubuntu-20.04           Running         2

最後に適当な WSL コマンドを実行して Linux のコマンドが動作することを確認します。 Windows 上からは wsl {command} の形式でコマンドを実行するか、 wsl コマンドを実行して Linux 上にログインしてからコマンドを実行することができました。

wsl lsb_release -a
# No LSB modules are available.
# Distributor ID: Ubuntu
# Description:    Ubuntu 20.04 LTS
# Release:        20.04
# Codename:       focal

Docker

WSL 2 が Install できたら、次は Docker をインストールして実行してみます。

Install Docker Desktop

このページ Docker Desktop for Mac and Windows | Docker を開いて Installer をダウンロードします。ダウンロードした Installer を実行してください。 Install の途中で表示される Configuration は Enable WSL 2 Windows Features のチェックを外さないようにしてください。

Image from Gyazo

WSL 2 が正しく Install されている場合は General 画面の Use the WSL 2 based engine にチェックがついていることと、 Resources 画面の Enable integration with my default WSL distro にチェックがついているはずです。もしチェックがついていなければ、つけてください。

Image from Gyazo

Image from Gyazo

Get started

Docker Desktop を起動するとチュートリアルが始まります。手順通り実行していくと Container が起動します。 Container 起動後はブラウザで localhost にアクセスすることで、それっぽい画面が開けるようになります。画面確認後はゴミ箱アイコンをクリックして、 Container を削除してしまってよいです。

Image from Gyazo

Image from Gyazo

Docker コマンド実行確認

もちろんコマンドからも実行可能です。前と同じチュートリアルをコマンドで実行したい場合は、 Terminal を開いてこのコマンドを実行すると同じように、ブラウザでそれっぽい画面が開けるようになります。

docker run -dp 80:80 docker/getting-started

Image from Gyazo

参考にしたもの

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

dockerの-dオプション、デタッチドモードって何?

-dで実行されるモード。デタッチドモード。

docker-compose up -d nginx mysql

-dはデタッチドモードのオプション。
バックグラウンドでcontainerを立ち上げる。

バッググラウンドで立ち上げるとは?

バックグラウンドで立ち上げない場合は、コンソールがそのcontainerのログに専有されて他のコマンドを打つことができなくなる。

コンソールをコンソールとして使いたい場合、特にcontainerの挙動を見る必要がないときは-dオプションをつければよい。

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

rails generate migrationをdockerで立ち上げたRailsで実行したい

はじめに

dockerでRailsを立ち上げたら、Railsコマンド使えなかった。困った。
これは完全なる自分用の備忘録です。

既存DBのテーブルにカラムを追加したい

docker-compose exec app rails g migration AddSomeColumnsToHoge

appはdockerで立ち上がってるものです。appとかwebとかそんな名前で使われることが多い。(知らんけど)
AddSomeColumnsToHogeHogeはカラムを追加したいテーブル名にしました。

これでdb/migrate20200xxxxxx_add_some_columns_to_Hoge.rbファイルが作られます。
中身を見ると

20200xxxxxx_add_some_columns_to_Hoge.rb
class AddSomeColumnsToHygienists < ActiveRecord::Migration[5.2]
  def change
  end
end

こんな感じ。
ここに追加したいカラムを書いていく。

20200xxxxxx_add_some_columns_to_Hoge.rb
class AddSomeColumnsToHygienists < ActiveRecord::Migration[5.2]
  def change
    add_column :テーブル名, :カラム名, :
  end
end

こんな感じ。
追加したいカラムが複数ある時は下に追記していく。

型      意味
string 文字列
text 長い文字列
integer 整数
float 浮動小数
decimal 精度の高い小数
datetime 日時
timestamp タイムスタンプ
time 時間
date 日付
binary バイナリデータ
boolean Boolean

以上の型が指定できるみたい。

マイグレーションを実行

追加したいカラムがかけたらマイグレーションを実行

docker-compose exec app rake db:migrate

db/schema.rbでカラムを追加したテーブルを確認すると、カラムが追加されてます!やったね!

参考文献

最後に

dockerで立ち上げたらコマンドややこしいと個人的に感じたので備忘録。
今度は削除とか変更とかで躓きそう。
その時は追記します。
殴り書きなので、不備とかアドバイスとかいただけるとありがたいです。

書いておいてアレだけど、基本的には参考文献の記事を参考にすると解決します

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

dockerでローカルネットワーク専用にseleniumサーバー立てて、ブラウザ上で動作を確認できるように構築した

selenium使っていろいろ自動化とかテストとか行ってると同じタイミングで同じブラウザを立ち上げてたり、ブラウザのバージョンアップで不具合が出たり、ローカルの環境と切り離したSelenium環境が欲しくなる。

ちょうどいい家鯖(NAS用途メイン)があるので、そこにSeleniumサーバーを構築させたい。
かといって動作を確認できないとそれも不便なので何かしらの方法で動作も見たい。
とここまで考えたときにとあるところで、ブラウザからSeleniumの動作を見ることができるシステムを見た。
いろいろ調べるとguacamoleというオープンソースがVNCなどのプロトコルをHTTPにフォワードできるらしい。

ということで以下から本題。

使うDockerイメージ

selenium

公式にてwebdriver+browser+vncserverをバンドルしたイメージがいくつか提供されている。
https://github.com/SeleniumHQ/docker-selenium
selenium/standalone-chrome
selenium/standalone-firefox
seleniumはこのへんから
(単体で動かしてvncクライアントから確認しても良し)

guacamole

これも公式から
https://guacamole.apache.org/doc/gug/guacamole-docker.html
guacamole/guacd
guacamole/guacamole

と、したいところなんですが最新のイメージだとクライアント認証が必須なのでdbイメージも必要となっています。
ある程度公開されるサービスなら当然必須になると思いますが、ローカルネットワークくらいなら認証なんか別にいらない、
と思ってたらnoauthという拡張があったらしい。(1.0以降はなくなった)
https://guacamole.apache.org/doc/0.9.9/gug/noauth.html

こちらの場合はnoauthが使えるそのままのdockerイメージはないので、
https://guacamole.apache.org/releases/
noauthが使える0.9.14を使う。
guacamole/guacd:0.9.14
guacamole/guacamole:0.9.14
(guacdの方もバージョン合わせる。)

guacamoleのDockerfile

ということでnoauthの拡張を入れたguacamoleイメージを作りましょう。

noauth-extension

拡張と設定ファイルをイメージにCOPYするので適当なフォルダを作成する。ここでは./guacamoleという名前にしよう。

https://guacamole.apache.org/releases/0.9.14/
guacamole-auth-noauth-0.9.14.tar.gzをダウンロード、解凍。
中身はjarファイルなので、上のフォルダの配下にextensionsというフォルダを作り、そこに入れる。
./guacamole/extensions/guacamole-auth-noauth-0.9.14.jar
↑という配置にする。

guacamole, noauth-config.xml

各seleniumのvncと接続する設定ファイルも必要なので、./guacamoleに配置。
./guacamole/noauth-config.xml
↑という状態。
内容は

noauth-config.xml
<configs>
    <config name="google chrome" protocol="vnc">
        <param name="hostname" value="chrome" />
        <param name="port" value="5900" />
        <param name="password" value="secret" />
    </config>
    <config name="firefox" protocol="vnc">
        <param name="hostname" value="firefox" />
        <param name="port" value="5900" />
        <param name="password" value="secret" />
    </config>
</configs>

これでOK

Dockerfile

あとはguacamoleフォルダをベースイメージ内に入れて、そこにGUACAMOLE_HOMEを設定する。

FROM guacamole/guacamole:0.9.14

COPY guacamole /etc/guacamole
ENV GUACAMOLE_HOME /etc/guacamole

EXPOSE 8080

この8080ポートはWebアクセス用のポート、もし他で使われている場合は変更したりしましょう。

docker-compose

あとはdocker-composeで動かすだけ。

docker-compose.yml
version: '3'
services:
  guacd:
    image: guacamole/guacd:0.9.14
    restart: unless-stopped

  guacamole:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    ports:
      - "8080:8080"
    links:
      - guacd
    environment:
      GUACD_HOSTNAME: guacd

  chrome:
    image: selenium/standalone-chrome-debug
    restart: unless-stopped
    ports:
      - "4444:4444"

  firefox:
    image: selenium/standalone-firefox-debug
    restart: unless-stopped
    ports:
      - "4445:4444"

port

8080
 →HTTP用
4444
 →selenium-remote chrome用
4445
 →selenium-remote firefox用

docker-compose up -dで立ち上がったら、同じネットワーク上からのブラウザから
http://[ip or host]:8080/guacamoleでアクセス。
(ルートはtomcatのページが出ます。)

スクリーンショット 2020-05-15 16.51.22.png

こんな感じで出ますね。
あとはどちらのブラウザか選んで、seleniumをremoteでつなげばブラウザが立ち上がる。

rubyでselenium-remote(chrome) : おまけ

require 'selenium-webdriver'
driver = Selenium::WebDriver.for :remote, url: "http://[host or ip]:4444/wd/hub", desired_capabilities: :chrome
driver.get "https://www.google.com"

参考

参考にさせていただきました。ありがとうございます。
https://qiita.com/S_SenSq/items/758bbde01e801e2d1624

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

【Docker】.Net Coreアプリのコンテナ化

1. はじめに

こんにちは。@ruemura3です。

この記事では

  • .Net CoreでサンプルWeb APIを作成し
  • Dockerを使ってコンテナ化し
  • ブラウザからAPIに接続する

ための手順を解説します。Webアプリケーションでも手順はほぼ同じです。
実際に手を動かしてみてください。

Dockerがどんなものかのなんとなくのイメージを他記事で掴んでから見るといいと思います。

公式ドキュメントには、コンソールアプリケーションのコンテナ化のチュートリアルがあります。

必須コンポーネント

  • .NET Core 3.1 SDK
    現在どの SDK を使っているか確認するには、ターミナルでdotnet --info コマンドを使います。必ず3.1以上にしてください。

  • Docker Community Edition
    Dockerをインストールしていない人はここから

    2. サンプルWeb APIの作成

    まずはAPIを作成しますが、ここが分からない人がコンテナ化しようとはしないと思うのでさらっと流します。
    デプロイしたいAPIやアプリがある場合は、3. から読んでください。

1. Visual Studioの立ち上げ

2. 新規プロジェクトの作成

3. ASP.NET Core Webアプリケーションを選択

4. プロジェクト名の命名(ここではSampleApiとしています)

5. APIを選択
ここでAPIが作成されます。すでにサンプルAPIができていて、天気予報を返すAPIのようです。
起動すると
https://localhost:44315/weatherforecast
へ接続され、以下の天気予報のjsonが返ってきます。

[{"date":"2020-05-16T07:27:11.1199412+00:00","temperatureC":-2,"temperatureF":29,"summary":"Mild"},{"date":"2020-05-17T07:27:11.1233617+00:00","temperatureC":-4,"temperatureF":25,"summary":"Hot"},{"date":"2020-05-18T07:27:11.1233692+00:00","temperatureC":-14,"temperatureF":7,"summary":"Mild"},{"date":"2020-05-19T07:27:11.1233696+00:00","temperatureC":25,"temperatureF":76,"summary":"Balmy"},{"date":"2020-05-20T07:27:11.1233697+00:00","temperatureC":25,"temperatureF":76,"summary":"Bracing"}]

6. Web APIの発行
上のツールバーからビルド→SampleApiの発行をクリック
発行先の選択でフォルダーを選択してプロファイルを作成ボタンをクリック
発行ボタンをクリック
SampleApi/bin/Release/netcoreapp3.1/publish/ディレクトリにSampleApi.dllなど、その他ファイルが発行されていることを確認します。

3. Web APIのコンテナ化

作業の流れは以下です。

  1. Dockerfileの作成
  2. Dockerfileを用いてコンテナイメージを作成
  3. コンテナの作成・起動

1. Dockerfileの作成 と 2. コンテナイメージの作成

" .csproj" が含まれるディレクトリに "Dockerfile" という名前のファイルを作成します。これは拡張子のないただのDockerfileというファイルです。
このDockerfileをテキストエディタで開き、以下のように記述します。

Dockerfile
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1

mcr.microsoft.com/はMicrosoft Container Repository(MCR)を指しており、Microsoft公式のDocker Hubです。
そこのdotnet/core/にあるaspnetというコンテナイメージのバージョン3.1を取ってくるという感じです。

この状態で一度ターミナルでDockerfileがあるリポジトリに移動し、以下のコマンドを入力しましょう。
以降の処理は必ずDockerfileのあるディレクトリで行ってください。

docker build -t sample-image -f Dockerfile .

このコマンドによって、Docker により Dockerfile 内の各行が処理されます。

  • -t sample-imageは、イメージ(正しくはリポジトリ名)にはsample-imageという名前を付けてね。
  • -f Dockerfileは、Dockerfileというの名前のファイルを実行してね。(先ほど作ったDockerfile名と一致させる)
  • .は現在のフォルダで検索してね。

という意味です。

このコマンドが終了したらdocker imagesを実行し、以下のように2つのイメージがあることを確認します。

docker images
REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
sample-image                           latest              e6780479db63        4 days ago          190MB
mcr.microsoft.com/dotnet/core/aspnet    3.1                 e6780479db63        4 days ago          190MB

IMAGE IDが2つとも被っています。これは言ってしまえば、ただ名前をsample-imageにしただけでなにも変わっていないからです。

ここで再びDockerfileをテキストエディタで開き、2行目以降に以下の記述を追加しましょう。

Dockerfile
COPY bin/Release/netcoreapp3.1/publish/ App/
WORKDIR /App
ENTRYPOINT ["dotnet", "SampleApi.dll"]
  • 1行目は、現在の作業ディレクトリ下のbin/Release/netcoreapp3.1/publish/(サンプルAPIが発行された場所)をコンテナ内の/Appフォルダにコピーしてね。
  • 2行目は、コンテナ内の作業ディレクトリを/Appに変更してね。
  • 3行目は、コンテナ内の現在のフォルダで、dotnetコマンドでSampleApi.dllを起動してね。

という意味です。

もう一度docker build -t sample-image -f Dockerfile .を実行し、docker imagesを実行しましょう。
すると以下のようになります。

docker images
REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
sample-image                           latest              cd11c3df9b19        41 seconds ago      190MB
mcr.microsoft.com/dotnet/core/aspnet    3.1                 e6780479db63        4 days ago          190MB

IMAGE IDが変わっていることが分かると思います。
mcr.microsoft.com/dotnet/core/aspnetは公式が配布している.Net Coreアプリのためのコンテナイメージで、それに自分のAPIを載せたコンテナイメージがsample-imageです。

コンテナの作成・起動

コンテナの作成と起動は、docker createdocker startで行いますが、docker runとすると2つとも一気にやってくれます。
また、docker runでしか使えないオプションを使うのでこちらを用いましょう。

以下のコマンドを実行します。

docker run -d -p 80:80 --name sample-container
  • -dはバックグラウンドで実行してね。
  • -p 80:80は自分のPCの80番ポートと起動したコンテナの80番ポートを接続してね
  • --name sample-containerは作成・起動するコンテナにはsample-containerと名付けてね

という意味です。

APIへの接続

これでコンテナが起動し、localhostの80番ポートに接続したため、
http://localhost/weatherforecast/
へ接続するとAPIの実行結果が返ってきます。

[{"date":"2020-05-16T07:27:11.1199412+00:00","temperatureC":-2,"temperatureF":29,"summary":"Mild"},{"date":"2020-05-17T07:27:11.1233617+00:00","temperatureC":-4,"temperatureF":25,"summary":"Hot"},{"date":"2020-05-18T07:27:11.1233692+00:00","temperatureC":-14,"temperatureF":7,"summary":"Mild"},{"date":"2020-05-19T07:27:11.1233696+00:00","temperatureC":25,"temperatureF":76,"summary":"Balmy"},{"date":"2020-05-20T07:27:11.1233697+00:00","temperatureC":25,"temperatureF":76,"summary":"Bracing"}]

4. さいごに

業務で使う機会があり、今どきdockerが使えないのはまずいので使えるようにしました。
Dockerがどんなものかイメージがついていないと分かりにくいと思うのでそこは他の記事で保管してください。

ご質問等あればお気軽にどうぞ。

Twitter↓
@ruemura3

個人開発日記ブログもあります↓
りょうの個人開発日記

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

Databaseコンテナを構築(PostgreSQL編)

Databaseコンテナを構築(PostgreSQL編)

ソフトウェア開発に欠かせないデータベース環境をWindows ノートPCに構築します。

今回はPostgreSQL環境を構築します。

モチベーション

  • 開発用にPostgreSQL環境をノートPC上で構築したい。
  • ポート、ユーザ、スキーマの定義は起動時に自動的に設定してほしい。

手順

環境

  • Windows 10 Pro
  • Docker Desktop for Windows

設定ファイルの作成

  • ファイルは以下のようなディレクトリ構造で配置します。
{任意フォルダ}
 ├ docker-compose.yaml
 └ docker-entrypoint-initdb.d
   └ init.sh
  • docker-compose.yamlを作成します。
version: '3'
services:
db:
image: postgres:12-alpine
container_name: db-container
ports:
- 5433:5432
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: admin
volumes:
- /C/Task/RedmineWorkHICT/#7212/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d
  • init.shを作成します。
set -e
psql -U admin admin << EOSQL
CREATE TABLE Users(
  account_id        SERIAL PRIMARY KEY,
  account_name      VARCHAR(20),
  email             VARCHAR(100),
  password    CHAR(64)
);

CREATE TABLE UserStatus(
  status            VARCHAR(20) PRIMARY KEY
);
EOSQL

改行コードをLinuxに揃える

今回の環境はWindowsのなので改行コードによりdockerの実行がエラーになる場合があります。
以下を実施して、改行コードをLinuxに揃えておきます。

  • VSCodeの場合:右下の改行コードの箇所をLFにする。

VSCode_LineFeed

  • Vimの場合:以下のコマンドでCR改行コードを削除。

    :%s/^M//g

  • エラーがある場合は、以下コマンドでコンテナとユーザキャッシュを削除します。

docker-compose down -v
docker-compose build --no-cache
docker-compose up -

起動とチェック

  1. 以下コマンドで起動します。
docker-compose up -d
  1. PostgreSQLのコンソールまで入ります。
docker exec -it db-container bash
psql -U admin
  1. 適当にSQL文を発行して動作を確認します。

まとめ

上記手順で新規に環境を構築できました。

  • docker-compose.ymlで以下を定義する。
    • PostgresSQLのコンテナイメージ
    • ユーザとパスワード
    • ポート
  • init.shでスキーマの定義を自動的に設定する。

応用編

  • データが入った状態で開始したい場合には以下の方法があります。
    • init.shにInsert文も記述する。(少量向け)
    • バックアップデータからレストアする。
    • DBデータディレクトリをマウントする。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Docker] [Gitlab] Gitlab基本安裝

目的

這是一次安裝經驗紀錄,當我們需要自己架設 版本控管 環境時,以前用過幾個不同環境,最早是都放在github

之後到公司後好像許多公司都會自己做這段,之前是用GOGS但覺得沒那麼好用,後來無意間發現同事推薦這款發現功能真的挺齊全的就決定來使用看看

預先準備環境:Docker

安裝Gitlab

  1. 建立綁定資料夾
mkdir -p /docker/gitlab/config
mkdir -p /docker/gitlab/data #備份位置也會在這
mkdir -p /docker/gitlab/logs

2 . 安裝Gitlab

docker run -d -e "TZ=Asia/Taipei" -h gitlab 
-p 2222:22 \ #2222(外部監聽Port):22(Docker 內部對應Port) SSH用
-p 8888:80 \ #8888(外部監聽Port):80(Docker 內部對應Port) HTTP用
-p 8443:443 \ #8443(外部監聽Port):443(Docker 內部對應Port) HTTPS用
-v /docker/gitlab/config:/etc/gitlab \  mount  資料夾
-v /docker/gitlab/logs:/var/log/gitlab \
-v /docker/gitlab/data:/var/opt/gitlab \
--restart always  \
--name gitlab gitlab/gitlab-ce:latest

3.登入gitlab
gitlab1.png

gitlab2.png

這樣就完成了

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

Bitriseのステータスをモニターに表示して物理的に監視する

背景

  • Bitriseのワークフローが成功/失敗したらSlackに通知する仕組みはよくある
  • 物理的にモニターにステータスを表示するツールの紹介はあまり見ない

ツール

https://github.com/marcells/node-build-monitor
こんな感じで表示される
node-build-monitor.png
https://builds.mspi.es/ にデモがあるので見てみてください。
表示形式の変更や、失敗したら音を鳴らすなどの設定も可能です。

やってみる

GitHubのREADMEで詳細は記載されているので、ここではBitriseを使用したハッピーパスだけ紹介します。

{
  "monitor": {
    "interval": 300000,
    "numberOfBuilds": 12,
    "latestBuildOnly": false,
    "sortOrder": "date",
    "debug": false
  },
  "services": [
    {
      "name": "Bitrise",
      "configuration": {
        "slug": "BitriseでのアプリID",
        "token": "パーソナルアクセストークン"
      }
    }
  ]
}

最後に

Slackの通知でも気づくことはもちろんできますが、オフィスのサイネージなどで表示しておけばエンジニアだけでなく、PMやデザイナーなどのプロジェクトメンバー全員がCIのステータスを気にする意識が持てるので、そこから何かいいアクションに繋がればいいなと思います。

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

Bitriseのステータスをモニターに表示して物理的に監視するツールの紹介

背景

  • Bitriseのワークフローが成功/失敗したらSlackに通知する仕組みはよくある
  • 物理的にモニターにステータスを表示するツールの紹介はあまり見ない
  • 複数のCIサービスのステータスを1画面でみたい

ツール

https://github.com/marcells/node-build-monitor
こんな感じで表示される
node-build-monitor.png
https://builds.mspi.es/ にデモがあるので見てみてください。
表示形式の変更や、失敗したら音を鳴らすなどの設定も可能です。

やってみる

GitHubのREADMEで詳細は記載されているので、ここではBitriseを使用したハッピーパスだけ紹介します。

{
  "monitor": {
    "interval": 300000,
    "numberOfBuilds": 12,
    "latestBuildOnly": false,
    "sortOrder": "date",
    "debug": false
  },
  "services": [
    {
      "name": "Bitrise",
      "configuration": {
        "slug": "BitriseでのアプリID",
        "token": "パーソナルアクセストークン"
      }
    }
  ]
}

最後に

Slackの通知でも気づくことはもちろんできますが、オフィスのサイネージなどで表示しておけばエンジニアだけでなく、PMやデザイナーなどのプロジェクトメンバー全員がCIのステータスを気にする意識が持てるので、そこから何かいいアクションに繋がればいいなと思います。

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

dockerコンテナを使用せずに1台のマシンで複数のKnowledgeを立ち上げる

dockerコンテナを使用せずに、1台のマシンで複数のKnowledgeを立ち上げる方法を記載する。

概要

dockerを使用すれば、1台のマシンで複数のKnowledgeを立ち上げる事は容易であるが、各コンテナがtomcatを実行するためメモリの消費が激しい。

なるべくメモリを節約するため、1台のマシンでdockerを使用せずに複数のKnowledgeを立ち上げる。

tomcat8のインストール

apt update
apt install -y openjdk-8-jdk #必ずこれが完了してからtomcat8を入れる

apt install -y tomcat8

systemctl stop tomcat8

 関連記事
 https://qiita.com/panda1100/items/1718a6515a4ffa429bba

knowledge 1.13.1のインストール

# tomcat8のhome directoryに移動
cd /var/lib/tomcat8
# 複数のknowledgeを立ち上げるのに使用するディレクトリを作成
# dbは各knowledgeのdbファイルを格納する
# .app1, .app2, .app3は後ほど各knowledgeのbasePathに指定するディレクトリ
mkdir factory db .app1 .app2 .app3
chown tomat8:tomcat8 factory db .app1 .app2 .app3
# 複数のknowledgeを立ち上げるための準備をするディレクトリに移動
cd factory
# 元になるknowldge.warを取得
wget https://github.com/support-project/knowledge/releases/download/v1.13.1/knowledge.war
# 立ち上げる数の分、knowledge.warをコピーする
# コピー先のファイル名はコンテキストパスとして使用する
# 例 http://localhost:8080/app1
#   http://localhost:8080/app2
#   http://localhost:8080/app3
for app in app1 app2 app3
do
 cp knowledge.war $app.war
done
# 或いは、echo app1.war app2.war app3.war | xargs -n 1 cp -v knowledge.war

各Knowledgeの設定

複数のknowledgeを立ち上げるため、各warファイルを編集して各knowledge用の設定を書き込む。
まずは、warファイルから必要なファイルを抜き出す

jar xf knowledge.war WEB-INF/classes/{appconfig.xml,connection.xml}

appconfig.xmlsystemName,basePath,databasePathを編集する
basePathは先程作成した/var/lib/tomcat8/.app1を指定する
databasePath{user.home}以下のdbディレクトリを指定する

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<app>
    <systemName>app1</systemName>
    <envKey>KNOWLEDGE_HOME</envKey>
    <time_zone>Asia/Tokyo</time_zone>
    <basePath>{user.home}/.app1</basePath>
    <indexPath>{base.path}/index/</indexPath>
    <tmpPath>{base.path}/tmp/</tmpPath>
    <databasePath>{user.home}/db/</databasePath>
    <slidePath>{base.path}/slide/</slidePath>
    <logsPath>{base.path}/logs/</logsPath>
    <uploadMaxMBSize>500</uploadMaxMBSize>
    <hashIterations>100</hashIterations>
    <languages>
        <language>
            <label>jp</label>
            <value>ja</value>
        </language>
        <language>
            <label>us</label>
            <value>en</value>
        </language>
    </languages>
    <addUserProcess>org.support.project.knowledge.logic.AddUserProcessLogic</addUserProcess>
    <afterLangSelectPage>/open.knowledge/list</afterLangSelectPage>
</app>

connection.xmlURLを編集する。ここではapp1_dbに変更

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<connectionConfig>
        <name>connection</name>
        <driverClass>org.h2.Driver</driverClass>
        <URL>jdbc:h2:tcp://localhost/./app1_db</URL>
        <user>sa</user>
        <password></password>
        <schema>public</schema>
        <maxConn>5</maxConn>
        <autocommit>false</autocommit>
</connectionConfig>

2つのファイルの編集が終わったらwarに書き込む。

jar uf app1.war WEB-INF/classes/{appconfig.xml,connection.xml}
rm -rf WEB-INF # 不要なファイルを削除

続けてapp2, app3と作業する。(作業ディレクトリはfactory)

for app in app2 app3
do
  jar xf knowledge.war WEB-INF/classes/{appconfig.xml,connection.xml}
  sed -i "s@<systemName>knowledge</systemName>@<systemName>$app</systemName>@"  WEB-INF/classes/appconfig.xml
  sed -i "s@<basePath>{user.home}/.knowledge</basePath>@<basePath>{user.home}/.$app</basePath>@"  WEB-INF/classes/appconfig.xml
  sed -i "s@<databasePath>{base.path}/db/</databasePath>@<databasePath>{user.home}/db/</databasePath>@"  WEB-INF/classes/appconfig.xml

  sed -i "s@<URL>jdbc:h2:tcp://localhost/./knowledge_db</URL>@<URL>jdbc:h2:tcp://localhost/./${app}_db</URL>@"  WEB-INF/classes/connection.xml

  jar uf $app.war WEB-INF/classes/{appconfig.xml,connection.xml}
  rm -rf WEB-INF
done

設定の書き込みが終わったら、/var/lib/tomcat8/webapps以下にコピーする。(作業ディレクトリはfactory)

その前に/var/lib/tomcat8/work/Catalina/localhost以下に不要なキャッシュが残っていれば削除する。work以下に不要なものが無い状態で以下を実行。

cp app1.war app2.war app3.war ../webapps # /var/lib/tomcat8/webapps

最後に、tomcat8を起動する

systemctl start tomcat8

warが展開されているか確認

ls /var/lib/tomcat8/webapps
app1 app1.war app2 app2.war app3 app3.war

dbが作成されているか確認

ls /var/lib/tomcat8/db
app1_db.mv.db app2_db.mv.db app3_db.mv.db

ブラウザで接続して確認

http://localhost:8080/app1
http://localhost:8080/app2
http://localhost:8080/app3

URIをhttp://localhost:8080/ABC/app1のようにしたい時は、warのファイル名をABC#app1.warのようにしておくと良い。

ここまで来たら後はスクリプトで追加できるように。
確認もせず何も言わずにただだまって追加する漢なスクリプトをfactoryの下にaddなどで配置しておく。

#!/bin/bash
cd /var/lib/tomcat8/factory
cp knowledge.war ${1}.war
jar xf knowledge.war WEB-INF/classes/{appconfig.xml,connection.xml}
sed -i "s@<systemName>knowledge</systemName>@<systemName>${1}</systemName>@"  WEB-INF/classes/appconfig.xml
sed -i "s@<basePath>{user.home}/.knowledge</basePath>@<basePath>{user.home}/.${1}</basePath>@"  WEB-INF/classes/appconfig.xml
sed -i "s@<databasePath>{base.path}/db/</databasePath>@<databasePath>{user.home}/db/</databasePath>@"  WEB-INF/classes/appconfig.xml
sed -i "s@<URL>jdbc:h2:tcp://localhost/./knowledge_db</URL>@<URL>jdbc:h2:tcp://localhost/./${1}_db</URL>@"  WEB-INF/classes/connection.xml
jar uf ${1}.war WEB-INF/classes/{appconfig.xml,connection.xml}
rm -rf WEB-INF
mkdir /var/lib/tomcat8/.${1}
chown tomcat8:tomcat8 /var/lib/tomcat8/.${1}
cp ${1}.war /var/lib/tomcat8/webapps

使い方

cd /var/lib/tomcat8/factory
bash ./add SOME_NAME 
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MAC環境でVirtualBox+Vagrant+DockerでReact開発環境を作る╰(°ㅂ°)╯

#stayhomeの時間を活用して、「仮想環境」とか「コンテナ開発」とかに慣れ親しもうという魂胆です。作業を進める上でよくわからなかった点など、周辺情報を個人的な備忘録として残します。

ゴール

作ったり壊せたり自由にできる開発環境を立ち上げられるようになること。React.jsの勉強を始める予定なので、React.jsの雛形アプリをブラウザで表示させるところまでをゴールとする。

作業の流れ

ステップが多く、私のような初学者は、わからない部分を調べている間に迷子になることもしばしば。一つ一つの動作確認をしながら作業を進めていきます。

【前半戦:ホストOS側での作業】

  • 事前準備
    • vagrantプラグインの導入確認
  • VMの設定
    • vagrant初期化
    • Vagrantfileの編集
  • dockerとdocker-composeの導入
    • Dockerfileの作成
    • docker-compose.ymlの作成
  • ホストOSとゲストOS間のファイル同期の設定
    • mutagen.yml作成

【後半戦:ゲストOS側での作業】

  • VM起動
    • vagrantでVM起動
    • VMにssh接続
  • VMの動作確認
    • ホストOSとのフォルダ共有を確認
    • dockerとdocker-compose動作
  • React.jsの導入
    • Dockerコンテナの起動
    • 起動中のコンテナに入る
    • create-react-appのインストールとアプリのひな形作成
    • アプリの実行

教材

基本となる教科書はこちらの二冊(記事)です。
- Vagrantを使う「Mac最速のDocker環境」を初心者向けに解説【遅いMac for Dockerを卒業】
- DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる

その他、以下のQiita記事を参考にさせていただきました。
- Docker環境内でcreate-react-app
- Windows環境においてVirtualBox+Vagrant+DockerでReact開発環境を作る*Windows向けに書かれた記事ですが、仮想環境起動のパート以降の後半部分を中心に参考にしました。

作業ディレクトリ

作業を行うディレクトリは、ホームフォルダ下に置いてある開発(develop)ファイルにVM(仮想マシン)フォルダを作成。その配下にsample-pjなる場所を作りました。
/Users/home/develop/vm/sample-pj

実行環境・ソフトウェア・パッケージ・プラグイン

  • macOS Mojave version 10.14.6
  • VirtualBox Version 6.1.6
  • Vagrant 2.2.9
  • VirtualBox Image ubuntu/xenial64
  • Vagrant Plugin
    • vagrant-disksize
    • vagrant-hostsupdater
    • vagrant-mutagen
    • vagrant-docker-compose
  • Docker version 19.03.8
  • docker-compose version 1.24.0

前提

Vagrantを使う「Mac最速のDocker環境」を初心者向けに解説【遅いMac for Dockerを卒業】に習って、以下のステップまで進めた状態からスタートします。

  • VirtualBoxをインストール
  • Vagrantをインストール
  • Vagrant Boxをダウンロード
  • プラグインの導入
~/develop/vm/sample-pj
$ vagrant box list
ubuntu/xenial64 (virtualbox, 20200505.0.0)

$ vagrant plugin list
vagrant-disksize (0.1.3, global)
vagrant-docker-compose (1.5.1, global)
vagrant-hostsupdater (1.1.1.160, global)
vagrant-mutagen (0.1.2, global)

この↑状態が確認できたところから開始です(`ω´)

【前半戦:ホストOS側での作業】

VMの設定

vagrant初期化

~/develop/vm/sample-pj
$ vagrant init ubuntu/xenial64

# 上記コマンドを実行して、下のような結果が出てくれば完了。
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
何が起きたかチェーーーーーック( ·∀·)ノ
~/develop/vm/sample-pj
$ ls

# sample-pj(プロジェクトディレクトリ)内の構造を見てみると、
# Vagrantfileができていることが確認できます。
Vagrantfile

Vagrantfileの編集

Vagrantfileは、仮想機械を構築するための構成情報を記述するための設定ファイルです。

( ˘ω˘ )? 「Vagrantfileにどんなことが書かれているのか?」という疑問については、Vagrantにおける仮想マシンの設定に素敵な感じにまとまっているので、詳しくはそちらを参照ください。

~/develop/vm/sample-pj
# vimエディタでVagrantfileを開きます。
$ vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
(略)

Vimエディタの使い方については、Vim初心者に捧ぐ実践的入門などのQiita記事を参考にしてください。初見では、とっつきにくい見た目をしていますが、何度か触っているうちに慣れてきました。

早速、教科書=(Vagrantを使う「Mac最速のDocker環境」を初心者向けに解説【遅いMac for Dockerを卒業】)のVagrantのセットアップを参照して、Vagrantfileを編集します。

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
# /sample-pj/Vagrantfile
Vagrant.configure('2') do |config|

  # VMを立ち上げる際のboxの指定
  config.vm.box = 'ubuntu/xenial64'

  # VMに設定するホスト名
  # 後述のmutagen.yml内の記述と揃える必要があるので覚えて置くこと。
  config.vm.hostname = 'sample-app'

  config.vm.network :private_network, ip: '192.168.50.10'
  # ポートへフォワードの設定
  config.vm.network "forwarded_port", guest: 3000, host: 3000

  config.vm.provider :virtualbox do |vb|
    vb.gui = false
    vb.cpus = 4
    vb.memory = 4096
    vb.customize ['modifyvm', :id, '--natdnsproxy1', 'off']
    vb.customize ['modifyvm', :id, '--natdnshostresolver1', 'off']
  end

  config.disksize.size = '30GB'
  config.mutagen.orchestrate = true

 # config.vm.synced_folderは、ホストOSとゲストOS間で共有するフォルダを指定します。
  config.vm.synced_folder './', '/home/vagrant/app', type: "rsync",
    rsync_auto: true,
    rsync__exclude: ['.git/', 'node_modules/', 'log/', 'tmp/']

  # config.vm.provisionは、初回(VM作成時)に実行されます。
  # ここではDockerとdocker-composeの導入について書かれています。
  config.vm.provision :docker, run: 'always'

  # docker-compose の設定
  config.vm.provision :docker_compose,
    yml: "/vagrant/docker-compose.yml",
    compose_version: "1.24.0",
    run: "always"
end

ポートへフォワードの設定とdocker-composeのインストールについては、私が追記編集した部分です。

ポートフォワードの設定については、Vagrant + VirtualBoxで仮想環境側のポートをあけるを参考にしました。この記述なし(教科書通り)で作業を進め、ブラウザでhttp://localhost:3000/ でアプリを開いてみようとすると、ERR_CONNECTION_REFUSEDという下記のエラーが出てきて困ってしまいましたが、ポートフォワードの設定を加えて解決できました。

ブラウザ
This site can’t be reachedlocalhost refused to connect.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

docker-compose の設定ですが、教科書通りにconfig.vm.provision :docker_composeだけでは、vagrant up時にインストールされませんでした。バージョン情報などを追加し、無事インストールできるようになりました。原因は全くわかりません・・・。

dockerとdocker-composeの導入

Vagrantfileでは、config.vm.provisionの部分で、初回のvagrant up(VM作成時)にdockerとdocker-composeがインストールされるように設定してあります。以下では、docker-compose upによるコンテナ実行時に呼び出される、docker-compose.ymlとDockerfileの2つを作成していきます。

docker-compose.ymlの作成

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
# docker-compose.ymlを作成
vagrant@sample-app:~/app$ vi docker-compose.yml

# 下記のように書き換え
version: "3"
services:
  #コンテナ名。後ほど、この名前を指定してコマンドを叩くことになります。
  node: 
    build:
      # 参照するファイルのある場所を、docker-compose.ymlからの相対パスで指定。今回は同じ階層・同じフォルダ内にある。
      context: .
    # 参照するファイル。今回はDockerfile_nodeという名前です。
      dockerfile: Dockerfile_node 
    # ストレージの指定 ホストOS:ゲストOS
    volumes:
      - ./:/usr/src/app
    ports:
      - "3000:3000"
    # docker-compose up後、即コンテナが終了することなく、待機状態とする。
    tty: true

Dockerfileの作成

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
# Dockerfileを作る。docker-compose.ymlで指定した通り、今回はDockerfile_nodeという名前にします。
$ vi Dockerfile_node

# Dockerfileを編集
# どのイメージを基にするか。今回はreactの開発環境なので、node.jsを使用します。現時点で最新・コンパクトなバージョンを指定しました。
FROM node:14.2-alpine

WORKDIR /usr/src/app

作業ディレクトリ(WORKDIR)については、色々なサイトを見ましたが、Linux系では/usr/src/appがお作法になっているようです。「/usr/src/appとは?」という疑問に関しては、 Linux豆知識 217「/usr/src」ディレクトリを参照。

ホストOSとゲストOS間のファイル同期の設定

Vagrantfileの config.vm.synced_folderの記述で、ホストOSとゲストOS間で共有するフォルダを指定しましたが、config.vm.synced_folderによるファイル共有は、vagrant upによるVM作成時のみ実行されます。つまり、常時シンクロしてくれるわけではないそうです。

DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる - ファイル同期の手段に習って、ホストOSとゲストOS間のファイル同期は、後述のmutagenというプラグインを使います。

mutagen.yml作成

DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる - ファイル同期のソリューション 「Mutagen」参考に、mutagen.ymlを作成、編集していきましょう。

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
# touchコマンドでmutagen.yml新規作成
$ touch mutagen.yml 

# sample-pj(プロジェクトディレクトリ)内の構造を見てみると、mutagen.ymlが追加されているのが確認できます。
$ ls
# 実行結果↓
Vagrantfile mutagen.yml
~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
# multagen.ymlファイルを開く
$ vim mutagen.yml

# multagen.yml内を編集
sync:
  app:
    # 双方向同期モード 但し、alphaが優先、ベースになる
    mode: "two-way-resolved"
    # alphaとbetaでエンドポイントを指定
    alpha: "./"
    # sample-appというhostの中の、/home/vagrant/appディレクトリ
    # sample-appは、Vagrantfile内のconfig.vm.hostname = 'sample-app'で指定した名前と揃える必要があります
    beta: "sample-app:/home/vagrant/app"
    # ignore(=無視)なので、以下に掲げる内容を無視するということかな?
    ignore:
    # vcs....バージョン管理システム(Version Control System)のことかな?それがtrueとは...? よく、わかりませんでした・・・。
      vcs: true
      # 一連のパスで指示されているディレクトリは無視するということかな?この辺よくわかりませんでした・・・。
      paths:
        - "/node_modules"
        - "/log"
        - "/tmp"

( ˘ω˘ )? 「multagen.ymlが何をしてくれているのか?」という疑問については、以下を参考にしまして、掴め(たような気に)ました。

以上で、ファイル共有の設定が完了しました。

以下の4つのファイルが準備できた段階で、ホストOS側での作業は終了です。

~/develop/vm/sample-pj
$ ls
# 実行結果↓
Dockerfile_node     docker-compose.yml
Vagrantfile     mutagen.yml

【後半戦:ゲストOS側での作業】

ここからは、VMを起動させてゲストOS側でReactの開発環境を作っていきます。

VagrantでVM起動

早速、VMの起動へ。

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
$ vagrant up
ディレクトリ内をチェーーーーーック( ·∀·)ノ
~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
$ ls

# 実行結果↓
Dockerfile_node
Vagrantfile
docker-compose.yml
mutagen.yml
mutagen.yml.lock
ubuntu-xenial-16.04-cloudimg-console.log

作った覚えのない、ubuntu-xenial-16.04-cloudimg-console.logというファイルが新しくできていることがわかります。
( ˘ω˘ )? cloudimg-console.logって、何してくれるの?という疑問については、cloudimg-console.logとはを参考にしました。名前の前半のubuntu-xenial-16.04の部分は、仮想OSの種類に依るようです。

VMにssh接続

~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
$ vagrant ssh

# 実行結果↓
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-178-generic x86_64)
(略)
# Vagrantfileで指定したホスト名でターミナルが開く。
vagrant@sample-app:~$ 

vagrant@sample-app:~$ というように、ターミナルが表示されればOK。vagrantユーザーでsample-appというホスト(=ゲストOS)にログインされています。

VMの中身をチェーーーーーック( ·∀·)ノ
vagrant@sample-app
# /(ルートディレクトリ)配下にLinuxのディレクトリが並んでいます。
vagrant@sample-app:~$ cd /
vagrant@sample-app:/$ ls
# 実行結果↓
bin   home            lib64       opt   sbin  tmp      vmlinuz
boot  initrd.img      lost+found  proc  snap  usr      vmlinuz.old
dev   initrd.img.old  media       root  srv   vagrant
etc   lib             mnt         run   sys   var

仮想環境にゲストOSが導入されていることが確認できました。ちなみに、Linuxのディレクトリの構造についての参考URLはこちらLinuxのディレクトリ構造(一覧)を理解するを参照ください。

ホストOSとのフォルダ共有状況ををチェーーーーーック( ·∀·)ノ
vagrant@sample-app
# ~(ホームディレクトリ)
vagrant@sample-app:~$ cd 
vagrant@sample-app:~$ ls
# 実行結果↓
app


# appへ移動し、カレントディレクトリのパスを出力する
vagrant@sample-app:~/app$ pwd
# 実行結果↓ 
/home/vagrant/app #multagen.ymlファイルで指定したゲストOS側のエンドポイントと一致していることがわかります。


# appの中も見てみましょう。
vagrant@sample-app:~$ cd app
vagrant@sample-app:~/app$ ls
# 実行結果↓
Dockerfile_node     mutagen.yml
Vagrantfile         mutagen.yml.lock
docker-compose.yml  ubuntu-xenial-16.04-cloudimg-console.log

試しに、/app内でtestという名前でディレクトリを作成してみます。

vagrant@sample-app
# /app内でtestという名前でディレクトリを作成
vagrant@sample-app:~/app$ mkdir test
vagrant@sample-app:~/app$ ls

# 実行結果↓
Dockerfile_node
Vagrantfile
docker-compose.yml
mutagen.yml
mutagen.yml.lock
test  # 新しく作ったディレクトリ
ubuntu-xenial-16.04-cloudimg-console.log

一度、VMを離れて、ホストOS内の作業ディレクトリを見てみると、testという名前のファイルができているのが確認できました。

vagrant@sample-app
# exitでVMからログアウト
vagrant@sample-app:/vagrant$ exit

# 実行結果↓
logout
Connection to 127.0.0.1 closed.
~/develop/vm/sample-pj(ホストOS内プロジェクトディレクトリ)
$ ls

# 実行結果↓
Dockerfile_node
Vagrantfile
docker-compose.yml
mutagen.yml
mutagen.yml.lock
test # こちらにもtestディレクトリができています
ubuntu-xenial-16.04-cloudimg-console.log

# ファイルの共有が確認できたのでtestフォルダを削除します
$ rm -r test

# もう一度VMへssh接続
$ vagrant ssh

# 実行結果↓
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-178-generic x86_64)
(略)

VM側でのtestディレクトリが消えているか確認します。

vagrant@sample-app
vagrant@sample-app:~$ cd app
vagrant@sample-app:~/app$ ls

# 実行結果↓ こちらでもtestファイルが無くなっていました。
Dockerfile_node     mutagen.yml
Vagrantfile         mutagen.yml.lock
docker-compose.yml  ubuntu-xenial-16.04-cloudimg-console.log

以上で、ホストOSとのフォルダ共有が確認できました。

dockerとdocker-compose動作も併せて、チェーーーーーック( ·∀·)ノ
vagrant@sample-app
# dockerの動作チェック
vagrant@sample-app:~$ docker --version
# 実行結果↓
Docker version 19.03.8, build afacb8b7f0

# docker-composeの動作チェック
vagrant@sample-app:~$ docker-compose --version
# 実行結果↓
docker-compose version 1.24.0, build 0aa59064

バージョン情報が表示されて、dockerとdocker-composeが導入されていることが確認できました。

Dockerコンテナの起動

vagrant@sample-app
# /appディレクトリにてコマンド実行。バックグラウンドでの実行するため-dオプションをつけます。
vagrant@sample-app:~/app$ docker-compose up -d

# コンテナの実行状況を確認しましょう
vagrant@sample-app:~/app$ docker-compose ps
# 実行結果↓
   Name             Command          State           Ports        
------------------------------------------------------------------
app_node_1   docker-entrypoint.sh    Up      0.0.0.0:3000->3000/tc

実行中のコンテナに入る

vagrant@sample-app
# 実行中のコンテナに入る。node部分は、docker-compose.ymlで指定したコンテナ名。
vagrant@sample-app:~/app$ $ docker-compose exec node sh
# 実行結果↓ 以下が表示されれば無事にコンテナ内に入れています。
/usr/src/app # 

コンテナ内でcreate-react-appのインストールとアプリのひな形作成

vagrant@sample-app
# creat-react-appのインストール
/usr/src/app # npm install -g create-react-app

# react-sampleという名前でアプリのひな形を作成
/usr/src/app # create-react-app react-sample

/usr/src/app # ls
# 実行結果↓
Dockerfile
Vagrantfile
docker-compose.yml
mutagen.yml
mutagen.yml.lock
react-sample # 新しいreactアプリが立ち上がっています
ubuntu-xenial-16.04-cloudimg-console.log

アプリの実行

vagrant@sample-app
# react-sampleディレクトリに移動
/usr/src/app # cd react-sample

# react-sampleを実行
/usr/src/app/react-sample # yarn start
# 実行結果↓
Compiled successfully!

You can now view react-sample in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://172.18.0.2:3000

Note that the development build is not optimized.
To create a production build, use yarn build.

ゴォォォォォル(´∀`*)

ブラウザでhttp://localhost:3000 へアクセスしてみます。以下のような画面が出てくればOKです。

Screen Shot 2020-05-15 at 10.52.48.png

おまけ:再度コンテナに入る

一度コンテナを立ち上げた後、作業のためにコンテナに入るまでの手順はこちら。

# ホストOSの作業ディレクトリにて、VMを起動
ホストOS作業ディレクトリ $ vagrant ssh

# ゲストOSのreact-sampleアプリへ移動し、コンテナを実行
ゲストOS:~$ cd app
ゲストOS:~/app$ cd react-sample
ゲストOS:~/app/react-sample$ docker-compose up -d

# コンテナに入る
ゲストOS:~/app/react-sample$ docker-compose exec node sh

# コンテナ内
/usr/src/app #

ついでに、ソフトウェアの導入を確認。React.jsの開発ができる環境になっているようです。

/usr/src/app # node --version
v14.2.0
/usr/src/app # npm --version
6.14.4
/usr/src/app # yarn --version
1.22.4

以上!!

初・初・初学者です(´·ω·`)

暗中模索な感じで始めてしまい、うまくいかず途中で投げ出したくもなりましたが、なんとか動くところまで持ってこれました。多々、理解違いがあるかと思います。今後、間違いに気づいた点などは、適宜修正していこうと思います。

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

-dオプションつけてるのにDockerすぐに落ちちゃうんですけど〜〜!!!

はじめに

ぼくがはまったdockerに関する事象です。

docker-compose start が起動後すぐ落ちちゃうんですけど~

docker-compose up -dみたいに-dオプション付けてるにも関わらず、すぐ終了しちゃうんだ。
そんな時はdocker-compose.ymlとかに不備があるかも。
docker-compose logsでエラーが吐かれていないか確かめよう。
僕の場合はnginxのdefault.conf(nginxの設定を記述するファイル)のvolume先を間違えていたから起動後すぐ終了しちゃったよ。
修正したらちゃんと起動するはず。

今回はdocker-composeだったけど、dockerコマンドでも同様にdocker logs コンテナ名でログを確認できるよ。

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

X11を用いたLinux用バイナリファイルをDocker for Macを用いてMac上で楽に動かせるようにする

はじめに

発端は友人から大学院の授業で使う環境の構築で困ったから手伝ってくれって言われた事でした。
見てみると、ubuntu上で教授が用意したバイナリファイルを実行できるようにできれば良さそうでした。
Windowsは環境構築の方法が解説されて、Macは自力で頑張ってと言われたそうです?
Dockerを使えば実現できそうなのでやってみました。

リポジトリ

https://github.com/taka011002/docker-ubuntu-x11

今回使用したバイナリファイルは2次配布が禁止であった為リポジトリには含めていません。各自、実行したいバイナリファイルを用意してください。

環境

macOS Catalina: 10.15.4
Docker: 19.03.8
docker-compose 1.25.5
XQuartz 2.7.11 (xorg-server 1.18.4)

X11クライアントを各自変えてあげればmacOS以外でも動作すると思います。

ゴール

下記のコマンドで簡単に実行できる様にする。

$ make up
$ make #{実行したいバイナリファイル名}

手順

0. XQuartzを導入する

macにXQuartzを未導入の場合は導入してください。
XQuartzを用いる事でMacでX11アプリケーションを動作させる事ができる様になります。
brewを導入済みの場合は下記コマンドでXQuartzを導入できると思います。

$ brew cask install xquartz

導入後は再起動かユーザーのログアウトを行わないとXQuartzの設定の反映が行われないので注意してください。

1. XQuartzのネットワーク・クライアントからの接続を許可する

XQuartzを起動できる様にできたら、XQuartzを起動し、環境設定から「ネットワーク・クライアントからの接続を許可」にチェックを入れ、XQuartzを再起動してください。

2. Dockerfileを記述する

バイナリファイルを実行する環境のDockerfileを記述しています。
実行したいバイナリファイルによって各自変更してください。
x11関連のライブラリをapt-get installする際にタイムゾーンの設定等出てきてしまってビルドが進まなくなってしまった為、タイムゾーンを設定し、ENV DEBIAN_FRONTEND noninteractiveにて他の選択項目が出てきてしまっても進む様にしています。
今回はcommandsディレクトリにバイナリファイル(複数可)を配置する事を想定しています。

Dockerfile
FROM ubuntu:20.04

WORKDIR usr/workdir

# TZを設定する
ENV TZ Asia/Tokyo
RUN apt-get update \
    && apt-get install -y tzdata \
    && rm -rf /var/lib/apt/lists/* \
    && echo "${TZ}" > /etc/timezone \
    && rm /etc/localtime \
    && ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \
    && dpkg-reconfigure -f noninteractive tzdata

# 必要なライブラリのインストール
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update \
    && apt-get install build-essential x11-apps x11-utils x11-xserver-utils dbus-x11 -y \
    && apt-get install gedit -y \
    && apt-get install libgfortran4 -y

COPY commands/ ./commands
RUN chmod +x ./commands
ENV PATH /usr/workdir/commands:$PATH

この時点で実行できるといえばできるはずです。
参考:Docker for Mac で X11 アプリケーションを動かす

毎回長いコマンド打つのはめんどくさい、、、という気持ちの方は次の手順へ進んで下さい。

3. docker-coomposeを記述する

コンテナ側にホスト側のX11クライアントの情報を渡してあげる必要があり、コマンドを毎回打つのが面倒な為記述しました。
また、ホスト側srcディレクトリをコンテナ側/usr/workdir/srcディレクトリにマウントする様に記述しています。

docker-compose.yml
version: '3.7'
services:
  app:
    build: .
    volumes:
      - ./src:/usr/workdir/src
    env_file:
      - .env
    tty: true
    stdin_open: true

docker-compose.ymlから参照している.envは下記です。
この環境変数DISPLAYをもとにコンテナ内からXQuartzへアクセスしにいきます。

.env
DISPLAY=host.docker.internal:0

こちらの記事を参考に記述致しました。
host.docker.internalの実態としてはHost(Mac)側のhostnameを取得してくるそうです。
ここら辺の名前解決はDockerのバージョンによって推奨が違う為確認してください。

4. Makefileを記述する

毎回docker-composeコマンドを記述するのが面倒な為、Makefileを定義してあげてmakeコマンドで実行できる様にしました。
基本的にはdocker-composeをmakeで実行できるようにしています。
ポイントとしては、upで実行する際に自動的にXquartzを起動し、xhost +$(hostname)にてホスト(Mac)のhostnameでXquartzへアクセスできる様にしてコンテナ側との整合性を合わせています。
また、xhostでのアクセスはセキュリティリスクもある為気になる方は他の方法で認証してください。

Makefile
build:
    docker-compose build --no-cache

up:
    open -a Xquartz
    xhost +$(hostname)
    docker-compose up -d

down:
    docker-compose down

restart:
    make down
    make up

destroy:
    docker-compose down --rmi all --volumes

destroy-volumes:
    docker-compose down --volumes

ps:
    docker-compose ps

bash:
    docker-compose exec app bash

xeyes:
    docker-compose exec app bash -c 'xeyes'

#{実行したいバイナリファイル名}:
    docker-compose exec app bash -c '#{実行したいバイナリファイル名}'

4. 実行する

下記コマンドでdockerイメージをビルドします

$ make build

buildに成功すれば下記コマンドでdockerコンテナを起動できるはずです。

$ make up

起動できたら、コンテナ側からホスト(Mac)のXQuartzへアクセスできるかxeyesを用いてテストしてみます

$ make xeyes

このような目玉が表示されればコンテナ側からホスト(Mac)のXQuartzへアクセスできています。
image.png

後は実行したいバイナリファイルを各自配置し

$ make #{実行したいバイナリファイル名}

上記コマンドを下記の様に実行してください

$ make binary

また、下記コマンドを用いてコンテナへ入ることもできます。

$ make bash

まとめ

Dockerを用いればX11を用いたLinux用バイナリファイルもMac上のプログラムを動かすかの様に簡単に動作させる事ができた!

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

Pipenv から Poetry に移行するときに作った Dockerfile と タスクランナー

サンプルコード:https://github.com/tamanobi/poetry-with-docker-sample

次の点を踏まえて、 Pipenv から Poetry へ移行しました。そのときの知見をここに記します。

  • Pipenv はメンテナンス頻度が落ちていること
  • Pipenv のライブラリ依存解決の機能が遅く、解決できなくなることが多くなること

メンテナンス頻度の懸念は、安定しており変更もほぼ必要ない状態であれば問題ありません。しかし2つ目の問題が障害になりました。

Pipenv を使っている人は感じていると思いますが、 Pipenv の lock ファイル生成は長い時間がかかります。その遅さにしびれを切らした私はしばしば --skip-lock を入れてライブラリの動作検証を行なうこともしばしばありました。これは悪癖です。しかし、耐えられないほど長い時間であることも事実でした。

Poetry は lock ファイルの生成が非常に高速です。私は趣味プロジェクトで導入してから「これはいいぞ」と仕事のプロジェクトでも導入しました。パッケージマネージャーの移行作業は思ったよりもうまくいきました。ただし、多少工夫が必要でした。

Pipfile から pyproject.toml

まず最初にやったのは、 poetry init による pyproject.toml の生成です。実行すれば対話に答えていくだけで生成できます。デフォルトで問題ないはずです。

次に、 Pipfile の中身を適宜コピーして poetry add hogehoge することでした。表記に違いはほとんどないので、ただの作業でした。

めんどくさがりな私は次のような Pipfile に書かれた文字を1行に置換して poetry add しました。

mypy = "~=0.761"
pytest = "~=5.3.5"

mypy~=0.761 pytest~=5.3.5 のように整形し、 poetry add mypy~=0.761 pytest~=5.3.5 としました。開発用パッケージは、 poetry add --dev hogehoge でインストール可能です。

Poetry に対応した Dockerfile

Poetry の公式では、 pip によるインストールは推奨されていません。これは poetry が依存しているライブラリをインストールすることになるため、依存関係の解決が困難になる可能性があるからです。

そのため Dockerfile の中では、公式が推奨している get-poetry.py をダウンロードする手法を使います。公式の手法そのままだと、 poetry のバージョン固定ができません。常に最新版がインストールされます。回避するために、ダウンロード先を変更します。

ダウンロード先は GitHub だったので、 master となっているところを Git のタグで置換することができます。

- https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py
+ https://raw.githubusercontent.com/python-poetry/poetry/${POETRY_VERSION}/get-poetry.py

POETRY_VERSION という変数を変更すれば Poetry のバージョンを簡単にコントロールできます。

Poetry がライブラリをインストールするためには pyproject.toml と poetry.lock が必要なので COPY します。 poetry は export コマンドで requirements.txt を生成することができます。 -f は出力フォーマット、 -o は出力先ファイル名を指しています。出力フォーマットは現状では、 requirements.txt にしか対応していません

$ poetry export -f requirements.txt -o requirements.lock

今回作成した、 Dockerfile ではマルチステージビルドを利用していますが、必要でなければ無視してください。作成した Dockerfile の全体像を次に示します。

FROM python:3.8-slim as builder
WORKDIR /app
ENV POETRY_VERSION 1.0.5
ADD https://raw.githubusercontent.com/python-poetry/poetry/${POETRY_VERSION}/get-poetry.py ./get-poetry.py
COPY pyproject.toml poetry.lock /app/
RUN python get-poetry.py && \
    # Docker なので virtualenvs.create する必要がない。 see: https://stackoverflow.com/questions/53835198/integrating-python-poetry-with-docker/54186818
    /root/.poetry/bin/poetry config --local virtualenvs.create false && \
    /root/.poetry/bin/poetry export -f requirements.txt -o requirements.lock && \
    pip install -r requirements.lock

FROM python:3.8-slim as runner
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.8/site-packages /usr/local/lib/python3.8/site-packages
COPY . /app/

CMD ["python", "main.py"]

Pipfile にあったタスクランナーの機能が Poetry にはない

Pipenv ではタスクランナーの機能がついていました。Pipfile に記述しておけば pipenv run testpipenv run format というように独自のスクリプトが定義できる仕組みです。
不幸にも Poetry にはその機能がありません。似たような機能はありますが、ユースケースが異なります。その詳細については次に示すリンク先を読んでください。

そのため、タスクランナーを別途用意する必要があります。タスクランナーを自前で作ったり、そのためだけにライブラリを導入するのは無駄が多いです。今回は、 小さなタスクランナーを Makefile とシェルスクリプトで作成しました。

Makefile にはターゲットと実行コマンドを書きます。ターゲットは .PHONY に入れてファイルと競合しないように注意してください。また、引数が必要な実行については後述する注意が必要です。

.PHONY: isort black test flake8 say

format: isort black

isort:
    isort -rc .

black:
    black

flake8:
    flake8 --config .flake8

test:
    pytest .

Makefile で可変長変数をプロキシする

引数を受け取らないタスクランナーであれば、上述した記述で make format を打ち込むだけで簡単に isort と black が動作してくれます。これは非常に便利です。

しかし make の本来の用途であるビルドとは異なった使い方です。故に可変長引数の扱いが簡単ではありません。そこで、小さなシェルスクリプトで回避策を考えました。次に示します。

#!/bin/bash

TARGET=$1
shift
make "$TARGET" ARGS="$*"

これは make のラッパーです。 ./run-script test と書けば make test に展開されます。 第2引数以降は $* を利用することでスペースを含んだ文字列として Makefile の ARGS に展開できます。

例えば可変長引数を受け取りたい次のような make ターゲットが合ったとすると、 $(ARGS) の部分が第2引数以降として処理されます。

.PHONY: say

say:
    python -m scripts.main say $(ARGS)

この工夫によって、 Makefile とシェルスクリプトでタスクランナーが実現できます。

移行を終えて

移行の方法は以上です。パッケージマネージャーの移行作業はより骨が折れるかと思いましたが、案外簡単にすみました。実作業にして1時間です(調査時間は含んでいません)。

Pipenv を使っていてずっと悩んでいた依存解決や、遅さが Poetry を選択してからまったく気にならなくなりました。

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

【Docker】docker-maven-pluginでdocker:startするとContainer stopped with exit code 141 unexpectedly after ${time}ms while waiting on log out 'mysqld: ready for connections']で落ちる問題への対処【Maven】

TL;DR

ボリュームを使い切っていたことが原因だったため、クリーンアップしたら解決しました。

調査方法に関しての備忘用に書きます。

利用しているプラグイン

今回の件に直接は関係しませんが、利用しているプラグインはfabric8io/docker-maven-pluginです。

調査経緯

そのまま実行してもログには特に具体的なエラーは表示されず、何がどうエラーになっているか分からなかったため、mvn docker:start -Xとしてfull debug loggingを有効にして実行しました。
すると以下のようなログを見つけました。

[ERROR] InnoDB: Write to file ./ib_logfile101failed at offset 6291456, 1048576 bytes should have been written, only 393216 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.' [Pattern: mysqld: ready for connections] [thread: 17]

要するにディスク周りを調べろということだったので色々検索し、docker volume pruneするとエラーが解消しました。

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

(備忘録)Docker Compose(1コンテナだけ)でTensor Flow環境構築時のメモ

はじめに

自分の備忘録用です:sweat:
Docker Compose(1コンテナだけ)でPython+TensorFlow+Kerasの環境を作る時のメモです。
自分用に作った記事なので、分かりにくい点や情報、技術が古いかもしれませんがご了承ください:bow_tone1:

参考資料

参考にさせて頂きました:bow_tone1:

環境 ※以下のVerでなくても動くと思いますが、古いのでご注意下さい:no_good_tone2:

Ubuntuバージョン
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Dockerバージョン
$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b7f0
 Built:             Wed Mar 11 01:25:46 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:24:19 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
Docker-Composeバージョン
$ docker-compose version
docker-compose version 1.25.5, build unknown
docker-py version: 4.2.0
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.1c  28 May 2019

※なぜかbuild unknown。時間掛かりそうだったので諦めました:sob:

ディレクトリ構成

テスト用で適当に作っています。。。

dk_ai_dir
├── Dockerfile
├── docker-compose.yml
├── requirements.txt
├── src1

必要なファイルの中身

docker-compose.yml
version: '3'
services:
  dk_ai:
    restart: always
    build: .
    container_name: 'dk_ai'
    tty: true
    volumes:
      # マウントするディレクトリ
      - .:/dk_ai_dir
    ports:
      # ホスト側のポート:コンテナ側のポート
      - 7000:7000
Dockerfile
FROM ubuntu:18.04

WORKDIR /dk_ai_dir
COPY requirements.txt /dk_ai_dir

RUN apt-get -y update \
    && apt-get -y upgrade \
    && apt-get install -y --no-install-recommends locales curl python3-distutils vim ca-certificates \
    && curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py \
    && python3 get-pip.py \
    && pip install -U pip \
    && localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8 \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* \
    && pip install -r requirements.txt --no-cache-dir

ENV LANG en_US.utf8
requirements.txt
Flask==1.1.0
gunicorn==19.9.0
Keras>=2.2.5
numpy==1.16.4
pandas==0.24.2
pillow>=6.2.0
python-dateutil==2.8.0
pytz==2019.1
PyYAML==5.1.1
requests==2.22.0
scikit-learn==0.21.2
sklearn==0.0
matplotlib==3.1.1
tensorboard>=1.14.0
tensorflow>=1.14.0
mecab-python3==0.996.2

docker-compose ビルド(backgroundで起動)

$ docker-compose up -d --build

docker-compose イメージ情報を表示

$ docker-compose images
Container     Repository       Tag       Image Id       Size  
--------------------------------------------------------------
dk_ai       dk_ai_dir_dk_ai   latest   6f8b190eba7e   2.103 GB

作り方が悪いのか結構容量大きいような:sweat:

コンテナの一覧表示

$ docker-compose ps
Name     Command    State           Ports         
--------------------------------------------------
dk_ai   /bin/bash   Up      0.0.0.0:7000->7000/tcp

コンテナに接続

$ docker-compose exec dk_ai /bin/bash
root@ddc90c65586d:/dk_ai_dir# pwd
/dk_ai_dir

できているか中身を確認

出力結果の表示が長いのでいくつか省きました:sweat:

root@ddc90c65586d:/dk_ai_dir# pip3 list
Package                Version
---------------------- -----------
absl-py                0.9.0
Flask                  1.1.0
gunicorn               19.9.0
h5py                   2.10.0
joblib                 0.14.1
Keras                  2.3.1
Keras-Applications     1.0.8
Keras-Preprocessing    1.1.2
matplotlib             3.1.1
mecab-python3          0.996.2
numpy                  1.16.4
pandas                 0.24.2
Pillow                 7.1.2
pip                    20.1
pyparsing              2.4.7
python-dateutil        2.8.0
requests               2.22.0
rsa                    4.0
scikit-learn           0.21.2
scipy                  1.4.1
setuptools             46.3.0
sklearn                0.0
tensorboard            2.2.1
tensorboard-plugin-wit 1.6.0.post3
tensorflow             2.2.0
tensorflow-estimator   2.2.0
urllib3                1.25.9
wheel                  0.34.2

一応、dockerコマンドでも確認

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
dk_ai_dir_dk_ai     latest              6f8b190eba7e        29 minutes ago      2.1GB
webque-api-img      latest              d0aa942613bc        9 days ago          1.9GB
python              3                   4f7cd4269fa9        2 weeks ago         934MB
ubuntu              18.04               c3c304cb4f22        2 weeks ago         64.2MB
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                    NAMES
ddc90c65586d        dk_ai_dir_dk_ai     "/bin/bash"         30 minutes ago      Up 30 minutes       0.0.0.0:7000->7000/tcp   dk_ai
860f6e3c6376        webque-api-img      "/bin/bash"         8 days ago          Up 2 days           0.0.0.0:8888->8888/tcp   webqueapi

今回作った物(dk_ai_dir_dk_ai)以外の物は、過去に作ったものです。結構容量大きいような:sweat:

サービス停止

$ docker-compose stop
Stopping dk_ai ... done
$ docker-compose ps
Name     Command    State    Ports
----------------------------------
dk_ai   /bin/bash   Exit 0        

サービス開始

$ docker-compose start
Starting dk_ai ... done
$ docker-compose ps
Name     Command    State           Ports         
--------------------------------------------------
dk_ai   /bin/bash   Up      0.0.0.0:7000->7000/tcp

環境をクリーンにしたい時

※参考資料そのままです。詳細は参考資料等見て下さい:bow_tone1:

# 停止&削除
# コンテナ・ネットワーク
docker-compose down

# コンテナ・ネットワーク・イメージ
docker-compose down --rmi all

# コンテナ・ネットワーク・ボリューム
docker-compose down -v
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む