What's New Qiita

20190209のdockerに関する記事は7件です。

  • 投稿日：2019-02-09T18:54:50+09:00

【 docker ... create ... コマンド無し 】docker-compose.yml だけで複数の docker-compose 間の volume、network を共有する知見まとめ

本記事の流れ

  • はじめに
  • 読者の想定
  • この記事に書いてあること
  • 共有の手順と動作確認
    • volume 共有設定と動作確認
    • network 共有設定と動作確認
  • さいごに

はじめに

こんにちは、Anyflow 株式会社 ( 株式会社ピケから社名を変更 ) の古内と申します。
以前、Django, DRF の記事を書きました。( Django REST Framework で API サーバーを実装して得た知見まとめ(OAuthもあるよ） )

今回は docker-compose についての知見を共有しようと思います。
知見を共有しようと思った経緯は以下のような感じです。

  1. サーバサイドの docker-compose が複数になってしまった
  2. 1 つの docker-compose にはしたくない
  3. docker network create ... 的な事前に専用のコマンド叩きたくない
  4. docker-compose up コマンドだけで環境を作れるようにしよう！

です。

イメージ的には

DockerCompose.png

がゴールです。

こちらのサンプルコードを例に解説していきます。
https://github.com/furuuchitakahiro/shared-docker-compose-example

今回の知見が何かの助けになれば幸いです。

読者の想定

  • docker の使用経験がある
  • docker-compose の使用経験がある

この記事に書いてあること

今回の記事はでは開発環境を docker-compose で運用している人を想定しています。
理由は、弊社では開発環境を docker-compose、本番環境を GCP の GAE などのマネージドの環境で運用しているため、開発環境の docker-compose をセキュアでスケールする必要がないためです。 ( そもそも本番に docker-compose ってあんまりないとは思いますが )
また、今回の記事では特に Django などのフレームワークや MySQL などのデータベース等の実装のことも書いていません。
基本的にコンテナの管理 ( docker-compose ) のみに焦点を当てています。

共有の手順と確認

それでは先程も載せましたがこちらのソースコードで軽い説明をしていきます。
https://github.com/furuuchitakahiro/shared-docker-compose-example

実際に動かしてやりたい方のコマンドは以下になります。( 2. と 3. の順番は大切です )

  1. git clone https://github.com/furuuchitakahiro/shared-docker-compose-example.git
  2. cd shared-docker-compose-example/master_docker-compose && docker-compose up
  3. 別のターミナルを開いて cd shared-docker-compose-example/slave_docker-compose && docker-compose up

このリポジトリのコンセプトとしては master_docker-compose が親になり、そこに紐づく子として slave_docker-compose の関係になります。
そのため最初に親の docker-compose を立ち上げなければ volume と network が Docker 上に生成されないので slave_docker-compose の初期化ができません。
一度親の docker-compose を立ち上げさえすれば大丈夫です。
重要なことは docker-compose up コマンドの順番だけです。

volume 共有設定と動作確認

それではまず、 volume を見てみます。
2 つの docker-compose は動かしている前提です。

まずは設定です.

shared-docker-compose-example/master_docker-compose/docker-compose.yml ( 親の docker-compose.yml )
12 ~ 18 行目

volumes:
  master_volume:
    driver: local
    driver_opts:
      device: ${PWD}/master_service/src
      type: volume
      o: bind

この設定で docker-compose up を実行すると volume が生成されます。
${PWD} の設定部分がミソです。これでカレントディレクトリ ( docker-compose.yml のあるディレクトリ ) を指定できます。
次に、子の docker-compose を立ち上げて親の volume をマウントします。

shared-docker-compose-example/slave_docker-compose/docker-compose.yml ( 子の docker-compose.yml )
13 ~ 16 行目

volumes:
  master_volume:
    external:
      name: master_docker-compose_master_volume

この設定で親の volume をマウントできます。
試しに、slave_service コンテナを操作して確認してみましょう。

  1. cd shared-docker-compose-example/slave_docker-compose
  2. docker-compose exec slave_service sh
  3. ls src/master_volume/

hoge.txt が存在していることが確認できると思います。

以上が設定と動作確認となります。

もし、あなたの環境の親の docker-compose で volume を定義したあと volume 名を確認するときは docker volume ls コマンドで確認できます。
今回のケースで上記のコマンドを実行すると

DRIVER              VOLUME NAME
...
local               master_docker-compose_master_volume
...

のように表示されます。
この表示された VOLUME NAME を子の関係の docker-compose.yml に設定すれば大丈夫です。

network 共有設定と動作確認

続いて network になります。
volume と同様に 2 つの docker-compose は動かしている前提です。

network の設定では親の docker-compose.yml の設定必要ありません。
子の docker-compose.yml の設定のみです。

shared-docker-compose-example/slave_docker-compose/docker-compose.yml ( 子の docker-compose.yml )
19 ~ 22 行目

networks:
  default:
    external:
      name: master_docker-compose_default

この設定で親のネットワークに接続できます。
試しに、slave_service コンテナを操作して確認してみましょう。

  1. cd shared-docker-compose-example/slave_docker-compose
  2. docker-compose exec slave_service sh
  3. ping master_service

以下のように表示されるはずです。

PING master_service (172.29.0.2): 56 data bytes
64 bytes from 172.29.0.2: seq=0 ttl=64 time=0.145 ms
64 bytes from 172.29.0.2: seq=1 ttl=64 time=0.160 ms
64 bytes from 172.29.0.2: seq=2 ttl=64 time=0.160 ms
64 bytes from 172.29.0.2: seq=3 ttl=64 time=0.242 ms
...

親と子の間で通信できていることが確認できました。

以上が設定と動作確認となります。

もし、あなたの環境の親の network を確認する際は docker network ls コマンドで確認できます。
今回のケースで上記のコマンドを実行すると

NETWORK ID          NAME                            DRIVER              SCOPE
...
04cc93553967        master_docker-compose_default   bridge              local
...

のように表示されます。
この表示された NAME を子の関係の docker-compose.yml に設定すれば大丈夫です。

注意点として docker-compose の network を共有する際は各 docker-compose.yml のコンテナの host 名に気をつけましょう。

さいごに

いかがでしたでしょうか？
以上が docker-compose 間で volume と network を共有する知見でした。
お役に立てれば幸いです。

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

ノートパソコンGalleriaを使ってnvidia-dockerサーバもどき作ってみた2019年2月

初めての投稿です、こんにちは。サウスブリッジです。
今回は、ノートパソコンでDockerサービスを常時可動させる環境を作ろうとしたら 予想外にハマった のでその記録を残そうと思います。もう落ち着いた頃合いだと思ったんだけどな…

パーティション設定とOSインストール

まさかここから波乱だとは思わなかったんだぜ…

まずはいつもの手順でLinuxを導入します。
今回はUbuntu Desktop 18.04LTS 日本語Remixを使います。
選定理由は「ゆるふわな筆者にも扱いやすいから」その他諸々です。

とりあえずUbuntuを勢いでズバーンっ…ではなくインストール済みのWindowsをどうにかします。
未練がなければバッサリ消してもいいのですが、 なにせあのWindowsです 。気が変わったときにロストしたときの悔しみがスゴそうな方は、回復手段をいくつか用意しておきましょう。私は用意しました。その手順を含めて進めていきます。

まずは取説通りの手順でセットアップし、Microsoftアカウントに紐つけておきます。その後アップデートと再起動を繰り返し、Windowsを最新の状態にします。
次に取説通りの手順で回復ディスクを作成します。16GB以上のUSBメモリが必要だそうです。ナメきって8GBをブッ刺したら怒られました。ナメてました…作成した回復ディスクは取り外してラベルを貼り、近くに置いておきます。

ここからUbuntuを扱い始めます 。Windows上で、Ubuntu Japanese Teamホームページから.isoイメージを、以下に示した参考記事のリンクからUniversal USB Installerをダウンロードします。
(別のUbuntu機で作ったインストールメディアは何故か起動に失敗しました。情報も少ないのでインストールメディアはWindowsで作ることをオススメします。)
Ubuntu 18.04 LTS 日本語 Remix リリース
UbuntuのLive USBをつくる | MKTIAの備忘録
上に示した参考記事の手順に従ってUbuntuインストールメディアを作成します。用意するUSBメモリは4GBで十分です。DVDに入っちゃうからねぇ…

インストールメディアができたら、刺したままWindowsに再起動の指示を出します。ブートはインストールメディアに 切り替わってくれない のでDeleteキーを連打してBIOSに入ります。 Galleriaロゴが出る前 の画面が暗いうちから連打しましょう。
BIOSに入れたら設定をしておきます。ブート順を変更した後、後でつまづくので Secure Bootを切って おきましょう。(入れっぱなしだとGRUBのインストールに失敗します。)

再起動から開けるとUbuntuが試用版で起動しているはずです。ここでシステムディスクと回復ディスクをddでバックアップしておきます。以下の記事を参考にしました。
dd コマンドによるディスクバックアップ・リストアメモ | アプ研
バックアップ先は64GBぐらいの外部ドライブが転がっていればなんとかなりそうですが、私の自宅には転がっていなかったのでたまたま置いてあったSAMBA共有NASを使うことにしました。CIFSでのマウント方法は以下の記事を参考にしました。
LinuxからWindows共有フォルダをマウントする | Kapibara Tech Blog
マウントコマンドは手元の環境に合わせて以下のように少し変更しました。

terminal
$ mkdir /home/tmpBkup
$ sudo mount -t cifs -o username=,password=,vers=1.0 //共有サーバのアドレス/共有ディレクトリ名 /home/tmpBack

匿名利用を許可しているので、usernameとpasswordの指定はするように見せかけてしない状態で十分です。versの指定は1.0でないとエラーが出ました。ｳﾁの設備が骨董品なんですね、ﾄﾎﾎ…
あとはddでバックアップ祭りです。まずは$ fdisk -lでシステムディスクと回復ディスクのアタリをつけます。パーティション単位(/dev/sdb1)ではなくドライブ単位(/dev/sdb)のように指定したほうが面倒が無いです。geditあたりにコピペでメモっておきましょう。
バックアップを走らせるコマンドは以下のとおりです。

terminal
$ sudo dd if=/dev/sdb bs=64k | gzip -c > /home/tmpBkup/sdb.ddimg.gz

これでデータの吸い出しから圧縮、NASへの転送まで一気に進みます。CPUのスレッドが暇そうだったので新たに端末を開き、システムディスクと回復ディスク同時バックアップをやらせました。

バックアップが終わったらいよいよパーティション操作です。変な汗が出る作業ですね。ここで残念なお知らせです。WindowsはUEFI環境下にインストールすると 基本パーティションを4つ全部作りやがります 。(参考 : EFI/GPT ベースのハード ドライブ パーティション | Hardware Dev Center) 気が変わったときのためにデュアルブートにしておこうという思いは儚く消え去りました。吹っ切れながら パーティションテーブルごと消し飛ばしてやりましょう 。
Superキーを押してDashu検索からGpartedを起動し、システムディスクとデータディスクのアタリをつけておきます。まずはシステムディスクでパーティションテーブルを作成します。ディスクごとバックアップ済みなので迷わず消し飛ばせますねっ。GalleriaはUEFI環境なので、Ubuntu 16.04 その43 - UEFIでパーティションが一つもないHDDにUbuntuをインストールしようとすると、インストーラーがフリーズする不具合 | kledgebにならってパーティションを組んでいきます。
パーティションテーブルの種類はgptを選択し、先頭にEFIパーティションを作成します。256MB程度のfat32パーティションを作成し、bootフラグとespフラグを設定します。
残りのエリアは自由に使いましょう。私は48GBをLinux swapに、残りをシステム用のext4パーティションに設定しました。ついでにDドライブ相当のHDDをパーティションテーブルgpt、全領域をext4パーティションとして設定しました。なぜかパーティションの境目に1MBの空きエリアができたりするけど気にしないスタイルで行くんだぜ。

ディスクの準備ができたのでいよいよUbuntuをインストールします。ドライブの利用方法の設定(システム用パーティションを/に、データ用パーティションを/homeに使用し、それぞれフォーマットを行う)以外は何も考えずにスムーズに進みます。インストーラの作業が終わったら、指示通りに再起動すると そのままフリーズします 。(正確にはログアウトに失敗して操作を受け付けなくなります。) 予定調和です 。臆せずSysreq+Bで再起動させましょう。画面が暗くなったタイミングでDeleteキーを連打すればBIOSに入れるので、落ち着いてUSBメモリを引き抜き起動ドライブを変更し、システムを起動します。

入れたてホヤホヤのUbuntuが起動し、初期設定をして欲しそうな画面を出してこちらを伺ってきます。 まだコイツに手を付けてはいけません。完了間際でフリーズしやがります 。早急にnvidiaプロプライエタリドライバをインストールしましょう(openのnvidiaドライバがログアウト不良の原因です。)
SuperキーでDash検索を呼び出し、「Update」と入力して「ソフトウェアの更新」を起動します。隅っこにある設定ボタンを押し、「追加のドライバー」タブを開き「nvidia-driver-???」のラジオボタンに選択を入れます。エラーを吐いてこなければインストールは成功しています。
ついでにホームディレクトリ内の日本語ディレクトリ名を英語表記化しておきましょう。以下の記事を参考にコマンドを叩き、ディレクトリ名を一括変更します。
Ubuntuでホームディレクトリの中身を英語にする | @taiko19xx

terminal
$ LANG=C xdg-user-dirs-gtk-update

ここで一旦システムを再起動しましょう。念の為、
Sysreq+R→Sysreq+S→Sysreq+U→Sysyreq→B
の順でフラッシュメモリへの書き込みを済ませてから再起動します。正規の手順で再起動しようとすると ログアウトのタイミングでフリーズ して操作を受け付けなくなります。勇気を持ってSysreqで叩き斬りましょう。

無事に再起動に成功したら一安心です。ウズウズ待っていた初期設定画面に従って設定を済ませ、Ubuntuの初期設定を完了させましょう。特にLivePatchを適用しておくことを推奨します。再起動したくなくなるマシンですからねっ。

また、Dockerサーバを常時可動させてどこかに仕掛ける予定であれば、モニタ蓋を閉じてサスペンドに入られると大変困ります。ここで設定を変えておきましょう。以下の記事を参考にしました。
モニターを閉じるとサスペンドされるのを防止 | @tukiyo3
設定ファイルの一部を書き換えます。

terminal
$ sudo gedit /etc/systemd/logind.conf

該当行をコメントアウトし、設定値を書き換えて上書きします。

/etc/systemd/logind.conf
- #HandleLidSwitch=suspend
+ HandleLidSwitch=ignore

書き換えたら設定を反映させましょう。

terminal
$ sudo systemctl restart systemd-logind

Dockerの導入

お待たせしました。前座が既にスゴいのですが、 ここからが本番 です。

まずはDocker本体を下記の参考記事と公式ページを見ながらインストールします。
Ubuntuにdockerをインストールする | @tkyonezu
Get Docker CE for Ubuntu | docker docs
ついでにDockerコマンドをsudo無しで叩けるようにしておきましょう。
ユーザをdockerグループに入れる | @tifa2chan

terminal
$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu$(lsb_release -cs)stable"
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io

$ sudo groupadd docker
$ sudo usermod -aG docker $USER

次にdocker-composeをインストールします。
Install Docker Compose | docker docs

terminal
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

一旦再起動し、インストールが成功したか確認します。

terminal
$ docker run hello-world
$ docker-compose --version

nvidiaがいらない方はここまでで導入完了です。

ここからnvidia-dockerをインストールしていきますが、 バトルです 。一時期平和になったような気がしてたんですけど、いつの間にか闘いの形相を呈していました。びっくりポンです。
最近はnvidia-docker-runtimeに名を改めたようですね。公式の手順に沿って操作を進めましょう。
Repository configuration | nvidia-container-runtime

terminal
$ curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey |   sudo apt-key add -
$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list |   sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list
$ sudo apt update

$ sudo mkdir -p /etc/systemd/system/docker.service.d
$ sudo gedit /etc/systemd/system/docker.service.d/override.conf
/etc/systemd/system/docker.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --host=fd:// --add-runtime=nvidia=/usr/bin/nvidia-container-runtime
terminal
$ sudo systemctl daemon-reload
$ sudo systemctl restart docker

$ sudo gedit /etc/docker/daemon.json
/etc/docker/daemon.json
{
    "default-runtime": "nvidia"
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}
terminal
$ sudo pkill -SIGHUP dockerd

コレで適当なnvidia-dockerコンテナを探して立ち上げ、

terminal
$ docker exec -it 適当なコンテナの名前 /bin/bash
コンテナの中# nvidia-smi

で搭載されているnvidiaチップが認識されていればインストール成功です!

リバースプロキシの導入

ここまででnvidia-dockerでグリグリ遊ぶ環境はできましたが、人は欲望の塊ゆえ「自作サービスを立ち上げてLAN内で使えるようにしたい」とか思ってしまうものです。私は思ってしまいました。ていうかポートフォワードの管理がカオスになるのが割としんどい…
そこでここからは「自作サービス作ったらDockerサーバでdocker-compose up -dするだけでLAN内からサブドメインでアクセスできる」とかいうステキ環境を作っていきましょう。
( この記事をメッチャ参考にしました。
複数のWebアプリを1サーバーのDockerを使ってSSL対応のサブドメインで簡単に運用する | QUARTETCOM TECH BLOG )

まずはLAN内からdockerサーバへアクセスできるようにしていきます。dnsmasqをインストールしてDHCP+DNSサーバとして働かせます。私は既にDHCP用にRaspberry Pi上でdnsmasqを動かしていましたが、今から始めるのであれば先程完成したDockerサーバで動かすのも良いかと思います。
※手製DNSサーバが落ちると家中のインターネット接続がコケます。管理とメンテをしっかり行いましょう!

以下の記事を参考にしながらdnsmasqのインストールと設定を進めていきます。
Raspberry pi を DHCP + DNS サーバーにしたい | 子育てしながらエンジニアしたい
dnsmasqをインストールし、追加設定ファイルを読み込む設定にします。

terminal
$ sudo apt install dnsmasq
$ sudo gedit /etc/dnsmasq.conf

設定ファイル内該当行のコメントアウトを外します。

/etc/dnsmasq.conf
# Include another lot of configuration options.
- #conf-file=/etc/dnsmasq.more.conf
+ conf-file=/etc/dnsmasq.more.conf

追加設定ファイルを新規作成して中身を作っていきます。

terminal
$ sudo gedit /etc/dnsmasq.more.conf
/etc/dnsmasq.more.conf
domain-needed
bogus-priv

# ノリで決めたドメイン名を書いておく。
# 後ろをjpにしないと何故か後工程がうまく行かなかったのは何故なんだぜ。
local = /mynet.jp/
domain = mynet.jp
expand-hosts

# 自宅のLANは192.168.3.n/24で回してます。
# dhcp-range = DHCP割当範囲、サブネットマスク、貸出時間の設定
# のフォーマットで書きます。
# プロバイダ貸出ルータのDHCP機能は割当範囲
# 192.168.3.1～192.168.3.1とかにして封印しておきましょう。
dhcp-range = 192.168.3.10, 192.168.3.200, 255.255.255.0, 6h

# DHCPクライアントに通知するルータのアドレスはプロバイダ貸出ルータにしておきます。
dhcp-option = option:router, 192.168.3.1
# DHCPクライアントに通知するDNSサーバのアドレスは後述する自分のアドレスにします。
dhcp-option = option:dns-server, 192.168.3.5
# NTPサーバもここで指定するようなのでプロバイダ貸出ルータを指定しておきます
dhcp-option = option:ntp-server, 192.168.3.1

# DHCPサーバで固定貸出したい機器を登録します。もちろん自分もリストに入れておきます。
# dhcp-host = MACアドレス, 割り当てたいIPアドレス, ノリでつけるホスト名
# のフォーマットで書き連ねていきます。
dhcp-host = ho:ge:hu:ga:pi:yo, 192.168.3.5, docker-server

ここまででDHCPサーバとしては動くのですが、肝心のDNSサーバとしての動きがイマイチになるので別のファイルも書き換えておきます。

terminal
$ sudo gedit /etc/hosts
/etc/hosts
127.0.0.1   localhost
::1     localhost ip6-localhost ip6-loopback
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

# DNSサーバとしてこの名前を通知します。
127.0.1.1   docker-server

# ここから下は名前解決したいホストをリストしていきます。
# IPアドレス  名前解決したいオレオレドメイン付きアドレス  ホスト名
# のフォーマットでリストしていきます。
# とりあえず自分をリストに入れておきましょう
192.168.3.5  docker-server.mynet.jp  docker-server

ここまで設定できたらdnsmasqを再起動し、設定を反映させます。

terminal
$ sudo systemctl dnsmasq restart

ただ、IPアドレスの取り直しは勝手にやってくれないようなのでマシンごと再起動してもいいかもしれません…

DNSがうまく動いたら、リバースプロキシをDocker上に立ち上げます。jwilder/nginx-proxyというDockerイメージが ドチャクソ便利 なので早速使っていきます。
/homeディレクトリに適当な名前のディレクトリを作り、その中にリバースプロキシ用のdocker-compose.ymlを書いていきます。

/home/user/docker-service/service-proxy/docker-compose.yml
# ~/service-proxy/docker-compose.yml
version: '2.3'
services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./certs:/etc/nginx/certs:ro
      - /etc/nginx/vhost.d
      - /usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro
    restart: always
  letsencrypt-nginx-proxy-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nginx-letsencrypt
    volumes:
      - ./certs:/etc/nginx/certs
      - /var/run/docker.sock:/var/run/docker.sock:ro
    volumes_from:
      - nginx-proxy
    restart: always

networks:
  default:
    name: service_net

これでdocker-compose up -dするとリバースプロキシが立ち上がり、Dockerネットワークservice_netが作られます。ここに自作サービスコンテナ群を吊るすと自動で見つけてアクセスを振り分けてくれるというギミックです。ｽｹﾞｪｯ

お試しでTaiga.ioを動かしてみる

ものは試しで何かWebサービス的なものを乗っけてみましょう。ここは適当にアジャイルツールのTaigaを置いてみます。割とメンテナンスが続いてるDockerイメージが以下になるので、参考にしながら置いてみます。
GitHub - benhutchins/docker-taiga: Docker container for Taiga https://taiga.io
セットアップ方法は以下の記事を左脳にしました。
taigaでgsuiteのsmtpリレーを利用しようとしてはまった(未解決) | @obilixilido

まず/home/user以下の適当な場所でリポジトリをcloneします。

terminal
git clone https://github.com/benhutchins/docker-taiga-example.git mytaiga && cd mytaiga

設定ファイル2つと、docker-compose.ymlを編集、作成します。

./conf/taiga/local.py
# If you want to modify this file, I recommend check out docker-taiga-example
# https://github.com/benhutchins/docker-taiga-example
#
# Please modify this file as needed, see the local.py.example for details:
# https://github.com/taigaio/taiga-back/blob/master/settings/local.py.example
#
# Importing docker provides common settings, see:
# https://github.com/benhutchins/docker-taiga/blob/master/docker-settings.py
# https://github.com/taigaio/taiga-back/blob/master/settings/common.py

from .docker import *

# とりあえず一見様もアクセスできるようになります。
PUBLIC_REGISTER_ENABLED = True
# DEBUG = Trueにしておくとdocker-compose up(-d無し)で標準出力にログがデロデロ出てくるようになります。
DEBUG = True
TEMPLATE_DEBUG = False
./conf/taiga/conf.json
{
    "api": "http://taiga.docker-server.mynet.jp/api/v1/", # サブドメインをノリで決めて書いておきます
    "eventsUrl": null,
    "eventsMaxMissedHeartbeats": 5,
    "eventsHeartbeatIntervalTime": 60000,
    "eventsReconnectTryInterval": 10000,
    "debug": true,
    "debugInfo": true,
    "defaultLanguage": "ja",
    "themes": ["taiga"],
    "defaultTheme": "taiga",
    "publicRegisterEnabled": true,
    "gravatar": false,
    "feedbackEnabled": false,
    "privacyPolicyUrl": null,
    "termsOfServiceUrl": null,
    "maxUploadFileSize": null,
    "contribPlugins": []
}

docker-compose.ymlはgit cloneで出来たディレクトリの直下に配置します。

./docker-compose.yml
version: '2.3'

services:
  taiga:
    image: benhutchins/taiga
    # リバースプロキシが良きに計らってくれるのでポートフォワードを切っておきます。
    #ports:
      # - 80:80
      # - 443:443 # To enable SSL, uncomment this line
    depends_on:
      - postgres
    volumes:
      # I recommend specifying a volume that maps to taiga's media,
      # this way uploaded files are not lost during upgrades of the taiga image
      - ./media:/usr/src/taiga-back/media

      # If you'd like to store the configuration outside of the container,
      # uncomment this volume. This allows for easy changes to the configuration.
      - ./conf/taiga:/taiga

      #- ./ssl.crt:/etc/nginx/ssl/ssl.crt:ro # To enable SSL, uncomment this line
      #- ./ssl.key:/etc/nginx/ssl/ssl.key:ro # To enable SSL, uncomment this line
    environment:
      # 適当に決めたサブドメイン入りホスト名を入れておきます。
      # Your hostname (REQUIRED)
      TAIGA_HOSTNAME: taiga.docker-server.mynet.jp

      # Database settings
      # To use an external database, simply update these and remove the postgres
      # service from this docker-compose.yml file
      TAIGA_DB_NAME: taigadb
      TAIGA_DB_HOST: postgres
      TAIGA_DB_USER: postgres
      TAIGA_DB_PASSWORD: password
      TAIGA_SLEEP: 15 # when the db comes up from docker, it is usually too quick

      # SSL対応は…諦めた…
      TAIGA_SSL: "false" # To enable SSL, uncomment this line
      TAIGA_SSL_BY_REVERSE_PROXY: "false" # To enable SSL, handling by a reverse proxy, uncomment this

      # メールを送れないとユーザを作れません。捨て垢を作って設定しておきましょう
      # gmail側で「安全性の低いアクセス」を有効化しておかないとメール送信できないようです…
      # To use an external SMTP for emails, fill in these values:
      TAIGA_ENABLE_EMAIL: "True"
      TAIGA_EMAIL_FROM: no-reply@taiga.docker-server.mynet.jp
      TAIGA_EMAIL_USE_TLS: "True"
      TAIGA_EMAIL_HOST: smtp.gmail.com
      TAIGA_EMAIL_PORT: 587
      TAIGA_EMAIL_USER: dummy.account@gmail.com
      TAIGA_EMAIL_PASS: hogehogepiyopiyo

      # ※ここが大事！
      # リバースプロキシは環境変数VIRTUAL_HOSTを設定したコンテナを探して設定してくれます。
      # ノリで決めたサブドメインを含めたフルパスを書いておきましょう。
      # nginx reverse proxy
      VIRTUAL_HOST: taiga.docker-server.mynet.jp
      LETSENCRYPT_HOST: taiga.docker-server.mynet.jp
      LETSENCRYPT_EMAIL: your@email.com

    restart: always

  postgres:
    image: postgres
    environment:
      POSTGRES_DB: taigadb
      POSTGRES_PASSWORD: password
      POSTGRES_USER: postgres
    ports:
      - 5432
    volumes:
      # this helps prevent your postgres data from deleted
      - ./pgdata:/var/lib/postgresql/data

    restart: always

# ここも大事！
# リバースプロキシと同じネットワークにぶら下げましょう。設定は以下のとおりです。
networks:
  default:
    external: true
    name: service_net

ノリで決めたサブドメインを含めたフルパスは、dnsmasqにも登録しておきます。

/etc/hosts
# IPアドレスは親亀のアドレスを指定しておきます。
192.168.3.5  docker-server.mynet.jp  docker-server
+ 192.168.3.5  taiga.docker-server.mynet.jp  taiga

ここまで設定できたらdnsmasqを再起動し、設定を反映させます。

terminal
$ sudo systemctl dnsmasq restart

さぁ、docker-compose up -dしてサービスを立ち上げ、お好みのブラウザでhttp://taiga.docker-server.mynet.jp/にアクセスしてみましょう。リバースプロキシが自動でアクセスを振ってくれて、サービスにアクセスできるハズです。

うまくアクセスできた方、 おめでとうございます！お疲れさまです！ これで、

  • nvidiaを使える docker環境
  • マシンに簡単アクセスできる DNS環境
  • 自作サービスを簡単に設置できるリバースプロキシ
  • ついでに俺得プロジェクトを無尽蔵に管理できる アジャイルツール

がゴッソリ手に入りました。
作ったインフラを活かして、面白いサービスをジャンジャン作って動かしましょう！

それでは、楽しいDockerライフを！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-02-09T17:47:33+09:00

SSH サーバープロセスを実行する DockerイメージをMacで作成

バージョン

  • Mac

    • macOS Mojave 10.14.3

  • Docker

    • 18.09.1

Docker Desktop for Mac のインストール

  • 次の Docker Hub ページの 「Download from Docker Hub」
    https://docs.docker.com/docker-for-mac/install/

  • Docker Hub サイトにログインしていない場合は「Please Login To Download」
    Docker Hub のアカウントを作成してログイン状態になり 「Get Docker」

  • Docker.dmg を Mac にインストール

  • インストール後 Dokcerが起動すると、Macの上部メニューの側に Docker アイコンが表示されるので、クリックして 「Sing in」
    "Docker ID" のところはメールアドレスでもログインできるが、docker pullでエラーになるので、Docker ID を入力する。
    image.png
    image.png

*　ターミナルから docker バージョンの確認

$ docker version
Client: Docker Engine - Community
 Version:           18.09.1
 API version:       1.39
 Go version:        go1.10.6
 Git commit:        4c52b90
 Built:             Wed Jan  9 19:33:12 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       4c52b90
  Built:            Wed Jan  9 19:41:49 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Docker イメージを作成

基にする Docker イメージの確認

今回は、Docker Hub レジストリにある 公式の amazonlinux イメージを利用する

  • リポジトリの確認 
    $ docker search amazonlinux --limit 1
NAME                DESCRIPTION                                     STARS               OFFICIAL            AUTOMATED
amazonlinux         Amazon Linux provides a stable, secure, and …   572                 [OK]
  • amazonlinuxリポジトリのタグの確認 
    $ curl -s https://registry.hub.docker.com/v2/repositories/library/amazonlinux/tags/ | jq '.results[].name' | sort
"1"
"1-with-sources"
"2"
"2-with-sources"
"2.0.20190207"
"2.0.20190207-with-sources"
"2018.03-with-sources"
"2018.03.0.20190207-with-sources"
"latest"
"with-sources"

Dockerコンテナー内のSSHサーバーにログインするためのキーペアを作成

$ ssh-keygen -t rsa -m PEM

「-m PEM」とは
https://qiita.com/tonishy/items/91066b1391e5e772622f

Dockerfile の作成

  • Mac の適当なフォルダに次の内容で Dockerfile を作成する
  • サーバアカウントのuid/gidとか、sudo 設定は EC2 Amazon Linux のそれに寄せている
  • FROM amazonlinux:1
RUN yum install -y shadow-utils    ← groupadd コマンドを使うためにインストール
RUN groupadd -g 500 ec2-user
RUN adduser -u 500 -g 500 ec2-user
RUN usermod -aG wheel ec2-user
RUN mkdir -m 0700 /home/ec2-user/.ssh
RUN echo "公開鍵" > /home/ec2-user/.ssh/authorized_keys    ← 上で作成したものの中身をそのまま貼り付け
RUN chmod 0600 /home/ec2-user/.ssh/authorized_keys
RUN chown -R ec2-user.ec2-user /home/ec2-user/.ssh
RUN echo 'root:適当なものに' | chpasswd    ← 念の為に root のパスワードを設定
RUN yum install -y sudo
RUN echo "ec2-user ALL = NOPASSWD: ALL" > /etc/sudoers.d/cloud-init
RUN echo "ec2-user ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers.d/cloud-init
RUN chmod 0440 /etc/sudoers.d/cloud-init    ← ファイル名は何でもよい、とりあえず EC2 Amazon Linux のデフォに合わせた
RUN yum install -y openssh-server
RUN /usr/bin/ssh-keygen -A    ← SSH サーバーホスト鍵を作成
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Dockerfile をビルド

  • Dockerfiles ファイルのある同じフォルダで次を実行
    ※最初のビルドでは、Docker Hub レジストリから amazonlinux:1 のイメージをダウンロードするのでインターネットに接続していること

    $ ls
Dockerfile
　
$ docker build -t amazonlinux1 .

  • 出来上がったイメージを確認

    $ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
amazonlinux1        latest              f61c2d171ce7        26 seconds ago      363MB
amazonlinux         1                   7f001bfb59e5        32 hours ago        168MB
    下のイメージが amazonlinux:1 のオリジナルイメージ
    上のイメージがオリジナルイメージをDockerfileの内容でカスタマイズしたイメージ
    　
    Dockerfile を変更して再ビルドする場合は、上のイメージだけ削除して、下のイメージを残しておけば、ビルドのたびに Docker Hub レジストリから amazonlinux:1 のイメージをダウンロードする必要がない。

コンテナー作成とSSH接続確認

  • 次のコマンドで Dockerイメージからコンテナーを作成する

    $ docker run -d -p 127.0.0.1:2222:22 --name amazonlinux1 amazonlinux1

    「-p 127.0.0.1:2222:22」 はポートフォワーディング設定
    ローカルの 127.0.0.1:2222 接続を、コンテナーの22(ssh)へ繋げる

  • コンテナー確認

    $ docker ps
CONTAINER ID        IMAGE               COMMAND               CREATED             STATUS              PORTS                    NAMES
6d43e67dcb8b        amazonlinux1        "/usr/sbin/sshd -D"   3 seconds ago       Up 1 second         127.0.0.1:2222->22/tcp   amazonlinux1

  • Mac のターミナルからコンテナーのSSHサーバープロセスへSSHログイン

    $ ssh -i 秘密鍵 -l ec2-user 127.0.0.1 -p 2222
[ec2-user@6d43e67dcb8b ~]$ ← コンテナーのプロンプト

コンテナーの停止・削除、イメージの削除

撤収

  • コンテナーを停止
    停止するコンテナーの CONTAINER ID を確認 
    $ docker ps
CONTAINER ID        IMAGE               COMMAND               CREATED             STATUS              PORTS                    NAMES
6d43e67dcb8b        amazonlinux1        "/usr/sbin/sshd -D"   4 minutes ago       Up 4 minutes        127.0.0.1:2222->22/tcp   amazonlinux1
    コンテナーIDを指定して stop 
    $ docker stop 6d43e67dcb8b
6d43e67dcb8b
  • コンテナーを削除
    削除するコンテナーの CONTAINER ID を確認 
    $ docker ps -a
CONTAINER ID        IMAGE               COMMAND               CREATED             STATUS                          PORTS               NAMES
6d43e67dcb8b        amazonlinux1        "/usr/sbin/sshd -D"   6 minutes ago       Exited (0) About a minute ago                       amazonlinux1
    コンテナーIDを指定して削除
    $ docker rm 6d43e67dcb8b
6d43e67dcb8b
  • イメージを削除
    削除するイメージの IMAGE ID あるいは REPOSITORY:TAG を確認 
    $ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
amazonlinux1        latest              f61c2d171ce7        17 minutes ago      363MB
amazonlinux         1                   7f001bfb59e5        32 hours ago        168MB
    上のイメージから削除
    今回は REPOSITORY:TAG を指定して削除
    $ docker rmi amazonlinux1:latest
$ docker rmi amazonlinux:1
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-02-09T12:39:28+09:00

Windows10 HomeでDocker環境を構築

サーバーサイドの開発をするために

Dockerでローカル環境構築を検討したのですが、
Windows10 Homeだと、Docker Toolboxになるし・・・
WSLだとdocker-composeが動かないし・・・
ほかにどういう環境がイケてるのだろうかと調べてみると、
VagrantでVirtualBox上にCoreOSインストールしてDockerを動かすのが良いらしいです。
CoreOS使う利点としては下の３つかなと思いました。

  • docker-composeが動く
  • Dockerインストール済
  • 移植性が高い

下の３つをダウンロードして、適当にインストールします。

Vagrant

https://www.vagrantup.com/

Virtual Box

https://www.virtualbox.org/wiki/Downloads

CoreOS

https://github.com/coreos/coreos-vagrant

Vagrantのプラグインインストール

ファイル共有で使用する。
vagrant plugin install vagrant-winnfsd
※nfs形式以外で共有ディレクトリでnpm install実行するとエラーになります。
VirtualBoxと連携する場合は必要になるみたい
vagrant plugin install vagrant-ignition

Vagrantfileの編集

Windowsのファイルを共有する設定をします。

共有ディレクトリ指定
35行目　$shared_folders = {'Windows側' => 'CoreOS側'}

ポートフォワード指定

36行目 $forwarded_ports = {CoreOS側=> Windows側}

共有ディレクトリ指定

148行目 config.vm.synced_folder host_folder.to_s, guest_folder.to_s, id: "core-share%02d" % index, nfs: true, mount_options: ['nolock,vers=3,udp']
↓に変更
148行目 config.vm.synced_folder host_folder.to_s, guest_folder.to_s, id: "core-share%02d" % index, type: "nfs"
※nfs: trueオプションについて調べてみたけど情報が全然でてこない・・・・
　オフィシャルのマニュアル

適当な行にdocker-composeインストールコマンドを追加

      $get_compose = <<-'EOF'
        sudo mkdir -p /opt/bin
        sudo curl -L https://github.com/docker/compose/releases/download/1.23.2/docker-compose-`uname -s`-`uname -m` -o /opt/bin/docker-compose
        sudo chmod +x /opt/bin/docker-compose
      EOF

起動

CoreOSのページのReadmeに書いてあるとおりに vagrant upすれば起動するはず。
https://github.com/coreos/coreos-vagrant

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

Node-REDでOCIの管理を簡単にする（１）OCIのCLI+Node-REDのDockerを作成する

はじめに

筆者は長くSREをやってきたのですが、運用を簡単にするツールをごそごそするのが大好きです。今回は、IoTクラスタで有名なNode-REDを紹介しようと思います。SRE業界ではまだ無名なはずです。

筆者が最近お気に入りのOracleのAutonomous Databaseは動作中のスケールアップダウンができるとか使わないときは止めておけるとか、便利な機能がついてます。問題は、私が作業を終わらせてからちゃんとCPU数を減らしたりする操作をわすれることです。はい、よく忘れるのでツールでカバーするのです。

会社についたら、Oracle Cloudにサインインして操作して、帰りにまた操作するなんて多分無理なので、一発操作の仕組みを作ることにしました。CLIでシェルスクリプトを書けばいいのですが、他人にも簡単に使ってもらいたいということでNode-REDでグラフィカルにブラウザ操作できるようにします。

今回はDocker上に構築しています。将来的にはOKE上に管理用コンテナとして転がしておこうと思います。手元のMacbook Proに設定する方法もあったのですが、長く使っていて環境がごちゃごちゃのためoci cliがうまくセットアップできなかったので、Docker container上に構築しました。

Node-REDに似たものに、Apache NiFiなどがあります。データフロー開発で高速に簡単なツールを作ることができますので、SREのかたには有効活用していただきたいと思います。コマンドやAPI戻り値のjsonを解析して必要なものを取り出して別の処理にかける、みたいなことが簡単にできるのがメリットです。まずはNode-REDでいじりまわして、やり方がわかったらjqなどのコマンドでスクリプト化するのが良いのではないのでしょうか。

簡単セットアップ

以下から、git cloneして、make buildimage ; make createcontainer すれば使えるはずです。
最初にmake attach してからOCI CLIのセットアップをしてください。

https://github.com/damarinz/oraclelinux-nodered-ocicli

Docker Containerのセットアップ(手動)

DockerいりローカルPCで実行

docker pull oraclelinux
docker run -it -p 1880:1880 --name oci_cli_nodered oraclelinux

Docker内で実行　※あとでDockerfile化します。

yum groupinstall -y "development tools"
yum install -y bzip2-devel gdbm-devel libffi-devel   libuuid-devel ncurses-devel openssl-devel readline-devel   sqlite-devel tk-devel wget xz-devel zlib-devel
yum install -y vim
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.bash_profile
exec "$SHELL"
source .bash_profile
pyenv install 3.7.2
pyenv global 3.7.2

OCI_CLIのセットアップ

こちらの手順書に従って設定します。

https://community.oracle.com/docs/DOC-1019624

Node-REDのセットアップ(手動：Docker内)

Docker内のコマンドラインから設定していきます。

curl -sL https://rpm.nodesource.com/setup_11.x | bash -

yum install -y nodejs
npm install -g --unsafe-perm node-red
node-red &

＝＝＝中略＝＝＝

9 Feb 01:39:33 - [warn] rpi-gpio : Cannot find Pi RPi.GPIO python library
9 Feb 01:39:34 - [info] Settings file  : /root/.node-red/settings.js
9 Feb 01:39:34 - [info] Context store  : 'default' [module=memory]
9 Feb 01:39:34 - [info] User directory : /root/.node-red
9 Feb 01:39:34 - [warn] Projects disabled : editorTheme.projects.enabled=false
9 Feb 01:39:34 - [info] Flows file     : /root/.node-red/flows_14daa05f828b.json
9 Feb 01:39:34 - [warn]

---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.

If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.

You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------

9 Feb 01:39:34 - [info] Starting flows
9 Feb 01:39:34 - [info] Started flows
9 Feb 01:39:34 - [info] Server now running at http://127.0.0.1:1880/

これでNode-REDが動き出しました。

個人用備忘録　操作メモ。これから自動起動を仕込みます。

Docker起動　　docker start <container_id>
Dockerに入る docker exec -it oci_cli_nodered bash

動作確認

localhostの1880に、dockerの1880をバインドしてあるので、 以下URLをブラウザで叩きます。

http://localhost:1880

Node-RED_と_2___14daa05f828b____oci__docker_.png

コンソール画面が出てきたら、簡単なフローを書きましょう。Execノードで oci compute shape list を実行するサンプルです。コマンドの戻り値をdebugノードで表示しているので、右下にcompute shape名がずらっと出てきました。

あとはこの調子で、コマンドを書き換えれば操作をtimestampノードからボタン化したり定期実行ができるようになります。

Node-RED.png

Exec nodeはこんな感じです。ociコマンドがpyenvで動いているので、場所を指定してあげます。

 +Append msg.payloadはチェックボックスを外しましょう。

Node-RED.png

あとは、コマンドの部分を書き換えてあげて、timestampノードを定期実行か特定の時間に実行してあげればボタン操作でも定期実行でも簡単に設定ができます。実際には何らかの外部アクションを元に動かすのが良いでしょう。

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

Node-REDでOCIの管理をブラウザ操作可能にする（１）OCIのCLI+Node-REDのDockerを作成する

はじめに

筆者は長くSREをやってきたのですが、運用を簡単にするツールをごそごそするのが大好きです。今回は、IoTクラスタで有名なNode-REDを紹介しようと思います。SRE業界ではまだ無名なはずです。

筆者が最近お気に入りのOracleのAutonomous Databaseは動作中のスケールアップダウンができるとか使わないときは止めておけるとか、便利な機能がついてます。問題は、私が作業を終わらせてからちゃんとCPU数を減らしたりする操作をわすれることです。はい、よく忘れるのでツールでカバーするのです。

会社についたら、Oracle Cloudにサインインして操作して、帰りにまた操作するなんて多分無理なので、一発操作の仕組みを作ることにしました。CLIでシェルスクリプトを書けばいいのですが、他人にも簡単に使ってもらいたいということでNode-REDでグラフィカルにブラウザ操作できるようにします。

今回はDocker上に構築しています。将来的にはOKE上に管理用コンテナとして転がしておこうと思います。手元のMacbook Proに設定する方法もあったのですが、長く使っていて環境がごちゃごちゃのためoci cliがうまくセットアップできなかったので、Docker container上に構築しました。

Node-REDに似たものに、Apache NiFiなどがあります。データフロー開発で高速に簡単なツールを作ることができますので、SREのかたには有効活用していただきたいと思います。コマンドやAPI戻り値のjsonを解析して必要なものを取り出して別の処理にかける、みたいなことが簡単にできるのがメリットです。まずはNode-REDでいじりまわして、やり方がわかったらjqなどのコマンドでスクリプト化するのが良いのではないのでしょうか。

Docker Containerのセットアップ

DockerいりローカルPCで実行

docker pull oraclelinux
docker run -it -p 1880:1880 --name oci_cli_nodered oraclelinux

Docker内で実行　※あとでDockerfile化します。

yum groupinstall -y "development tools"
yum install -y bzip2-devel gdbm-devel libffi-devel   libuuid-devel ncurses-devel openssl-devel readline-devel   sqlite-devel tk-devel wget xz-devel zlib-devel
yum install -y vim
git clone https://github.com/pyenv/pyenv.git ~/.pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.bash_profile
exec "$SHELL"
source .bash_profile
pyenv install 3.7.2
pyenv global 3.7.2

OCI_CLIのセットアップ

こちらの手順書に従って設定します。

https://community.oracle.com/docs/DOC-1019624

Node-REDのセットアップ(Docker内)

Docker内のコマンドラインから設定していきます。

curl -sL https://rpm.nodesource.com/setup_11.x | bash -

yum install -y nodejs
npm install -g --unsafe-perm node-red
node-red &

＝＝＝中略＝＝＝

9 Feb 01:39:33 - [warn] rpi-gpio : Cannot find Pi RPi.GPIO python library
9 Feb 01:39:34 - [info] Settings file  : /root/.node-red/settings.js
9 Feb 01:39:34 - [info] Context store  : 'default' [module=memory]
9 Feb 01:39:34 - [info] User directory : /root/.node-red
9 Feb 01:39:34 - [warn] Projects disabled : editorTheme.projects.enabled=false
9 Feb 01:39:34 - [info] Flows file     : /root/.node-red/flows_14daa05f828b.json
9 Feb 01:39:34 - [warn]

---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.

If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.

You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------

9 Feb 01:39:34 - [info] Starting flows
9 Feb 01:39:34 - [info] Started flows
9 Feb 01:39:34 - [info] Server now running at http://127.0.0.1:1880/

これでNode-REDが動き出しました。

個人用備忘録　操作メモ。これから自動起動を仕込みます。

Docker起動　　docker start <container_id>
Dockerに入る docker exec -it oci_cli_nodered bash

動作確認

localhostの1880に、dockerの1880をバインドしてあるので、 以下URLをブラウザで叩きます。

http://localhost:1880

Node-RED_と_2___14daa05f828b____oci__docker_.png

コンソール画面が出てきたら、簡単なフローを書きましょう。Execノードで oci compute shape list を実行するサンプルです。コマンドの戻り値をdebugノードで表示しているので、右下にcompute shape名がずらっと出てきました。

あとはこの調子で、コマンドを書き換えれば操作をtimestampノードからボタン化したり定期実行ができるようになります。

Node-RED.png

Exec nodeはこんな感じです。ociコマンドがpyenvで動いているので、場所を指定してあげます。

 +Append msg.payloadはチェックボックスを外しましょう。

Node-RED.png

あとは、コマンドの部分を書き換えてあげて、timestampノードを定期実行か特定の時間に実行してあげればボタン操作でも定期実行でも簡単に設定ができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-02-09T10:30:11+09:00

Azure DevOpsのPipelinesでCIをまわす

やること

GitHub上にあるソースコードを、Azure DevOpsのPipelinesでCIをまわす。

GitHubへのpushをトリガーとして、CIが回り始め、ジョブの中でソースのビルドを実行し、Dockerイメージを作成し、作成したイメージをDocker HubにPUSHする。

前提

Azureにアカウントを作っている。

pipelineを作る手順

まず、Azure DevOpsにログインし、以下の画面に遷移して、pipelineを押下。

welcome_to_project.jpg

以下のような画面がでたら、New pipelineを押下。

create_pipeline.jpg

以下の画面で、GitHubを押下。

select_source.jpg

以下の画面で、Authorizeを押下。

oauth.jpg

以下の画面で、Authorize AzurePipelinesを押下。

oauth2.jpg

以下の画面で、GitHubのパスワードを入力。

confirm_password.jpg

以下のような画面から、連携したいリポジトリを選択。

select_repo.jpg

以下の画面で、Docker imageを選択。

configure_pipeline.jpg

デフォルトで以下のようなYAMLの生成が促されるので、Save and run押下。

default.jpg

Save and run押下。

save_and_run.jpg

ジョブが走る。成功したら以下のような画面になる。

success.jpg

以上の手順を実行すると、連携したGitHubリポジトリ上にazure-pipelines.ymlが生成される。
デフォルトだと以下のようなazure-pipelines.ymlが生成される。

# Docker image
# Build a Docker image to deploy, run, or push to a container registry.
# Add steps that use Docker Compose, tag images, push to a registry, run an image, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- master

pool:
  vmImage: 'Ubuntu-16.04'

variables:
  imageName: 'your-container-image-name:$(build.buildId)'

steps:
- script: docker build -f Dockerfile -t $(imageName) .
  displayName: 'docker build'

trigger:
- master

の部分で、masterへの変更が生じた際にジョブが流れますよ、と言っている。

pool:
  vmImage: 'Ubuntu-16.04'

の部分で、Azureのクラウド上でジョブを実行する際に使用するOSイメージを選択できる。

variables:
  imageName: 'your-container-image-name:$(build.buildId)'

の部分で、imageNameという変数に、your-container-image-name:$(build.buildId)を入れている。
build.buildIdはAzure DevOps側で事前に定義されている値。

事前定義されている値は以下参照。
https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops

steps:
- script: docker build -f Dockerfile -t $(imageName) .
  displayName: 'docker build'

の部分で、ここではdocker build -f Dockerfile -t $(imageName) .というコマンドを流しますよ、このジョブはコンソールやログにdocker buildという名前で表示させますよ、と言っている。

azure-pipelines.ymlを編集

現状だと、作成されたイメージのDocker HubへのPUSHはないので、azure-pipelines.ymlを編集する。
下記資料のPush an imageの部分を参考にして、以下のように変更する。

https://docs.microsoft.com/en-us/azure/devops/pipelines/languages/docker?view=azure-devops&tabs=yaml#push-an-image

# Docker image
# Build a Docker image to deploy, run, or push to a container registry.
# Add steps that use Docker Compose, tag images, push to a registry, run an image, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- master

pool:
  vmImage: 'Ubuntu-16.04'

variables:
- group: nannany_secret
- name: imageName
  value: 'simple-application-azure:$(build.buildId)'

steps:
- script: |
    docker build -f Dockerfile.maven -t nannany/$(imageName) .
    docker login -u nannany -p $(DOCKER_HUB_PWD)
    docker push nannany/$(imageName)
  displayName: 'docker build'

Docker Hubのパスワードはそのまま記述せずに、PipelinesのLibrary機能を用いて変数に格納された値を使用している。

library.jpg

結果確認

設定した通り、masterブランチに変更が入るたびにパイプラインが流れる。
結果の確認は、PipelinesのBuildsからみることができる。

build_result.jpg

また、Docker Hubにも登録されていることが確認できた。

dockerhub.jpg

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

日付別

タグ一覧