20191102のdockerに関する記事は11件です。

#docker で SOCKS proxy を利用して ssh サーバー経由の https 接続をする

docker run

docker run --name=socks-https-proxy -it --rm alpine sh

必要なライブラリの install

/ # apk add --update openssh curl

必要があれば local から コンテナに秘密鍵をコピーしておく

docker cp ~/.ssh/some.pem socks-https-proxy:/

SOCKS で proxy を起動する

起動させっぱなしにしておく

ssh -vND 8888 -i some.pem user@host

docker exec

同じコンテナにコンソールの別タブからアクセスする

$ docker exec -it socks-https-proxy  ash

curl

httpbin.orgというサービスで接続元のIPアドレスを確認

/ # https_proxy=socks://127.0.0.1:8888 curl -v https://httpbin.org/ip

{
  "origin": "YYY.YYY.YYY.YYY, YYY.YYY.YYY.YYY"
}

ssh接続しているサーバーのIPアドレスになっていたら成功。

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/2657

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

Oracle超初心者がmacで公式OracleDatabase19イメージをdocker-composeしてみた

この記事の目的

テスト環境を作るために、localにOracleDataBase19を用意しなければならないことになって必死に調べたので、忘備録も兼ねて。不備などありましたらご指摘お願いします。

環境

Mac OS Mojave(10.14.6)
Docker 19.03.4
Oracle docker-images
Oracle Database 19.3

流れ(記事内リンクあり)

Dockerをインストール

Oracle公式のdocker-imagesリポジトリを適当なディレクトリに設置

Oracle Databaseのzipをダウンロード

zipをdocker-imagesリポジトリ内適所に設置

docker-imageをビルド

docker-compose.ymlを作成

コンテナを作成

DB周りの設定

Dockerをインストール

公式からインストール。dockerについて詳しくはこちらの方が詳しく説明してくださっています。

Oracle公式のdocker-imagesリポジトリを適当なディレクトリに設置

Oracle公式のdocker-imagesリポジトリをクローンします。

$ git clone https://github.com/oracle/docker-images.git

このリポジトリに各バージョン(11gとか12cとか)用のdocker imageが入っているので、これを使ってローカルにdocker imageを作成していくことになります。

Oracle Databaseのzipをダウンロード

Oracle Databaseのソフトウェアダウンロードページから、Linux x86-64版をzip形式でダウンロードします。
このとき、Oraleプロファイルへの登録を求められるので、未登録の場合は登録します。
safariで自動解凍されてしまう場合は、safari->環境設定->一般において、「ダウンロード後"安全"なファイルを開く」という項目からチェックを外しておく必要があります。

zipをdocker-imagesリポジトリ内適所に設置

以前は docker-images/OracleDatabase/dockerfiles以下にバージョン名ディレクトリがあり、そこに設置していたようですが、記事作成現在はdocker-images/OracleDatabase/SingleInstance/dockerfiles以下のバージョン名ディレクトリ直下に設置するようになっています。
Downloadsディレクトリにダウンロードした場合は以下のようになります。(現時点での最新バージョンです)

$ cp /Users/[ユーザ名]/Downloads/LINUX.X64_193000_db_home.zip /[docker-imageを設置した場所]/docker-images/OracleDatabase/SingleInstance/dockerfiles/19.3.0

docker-imageをビルド

$ cd [docker-imageを設置した場所]/docker-images/OracleDatabase/SingleInstance/dockerfiles

$ ./buildDockerImage.sh -v 19.3.0 -e -i

ビルドのオプションは-hで確認できます。今回使用したオプションは、-vはバージョン指定、-eはEnterprise Editionであることの指定、-iはMD5チェックサムを無視することの指定です。
ビルドに時間がかかるのでしばらく待ちます。

以下のコマンドで作成されたイメージを確認できます。

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
oracle/database     19.3.0-ee           795668b74d8e        33 minutes ago      6.65GB
oraclelinux         7-slim              874477adb545        2 months ago        118MB

oracle/databaseというのがこのイメージの名称ですね。

docker-compose.ymlを作成

dockerコンテナを作成したい場所(アプリケーションのdockerディレクトリなど)にdocker-compose.yml(コンテナの設計書のようなもの)を作成します。

$ vi docker-compose.yml

docker-compose.ymlの書き方はこちらの方などが書いてくださっています。

docker-compose.yml
version: '2'
services:
  db:
    image: oracle/database:19.3.0-ee
    ports:
      - 1521:1521
      - 5500:5500
    volumes:
      - ./data:/opt/oracle/data
    environment:
      - ORACLE_PWD=password
      - ORACLE_PDB=pdb1

volumesに記載したdataディレクトリですが、こちらはデータマウント用に用意しておきます。こうすることで、コンテナを再度作成してもデータが消えません。また、こちらのマウントディレクトリ内から環境変数などを触ることもできる点も便利です。

コンテナを作成

コンテナ立ち上げのコマンドはこちらの方などが書いてくださっています。
一応ですが、docker-composeコマンドが効くのはdocker-compose.ymlの直上のディレクトリです。

$ docker-compose up

私は個人的に、itermの画面分割で、左でupして右でexecするのが気に入っていますが、ひとまず今回は立ち上げるところまでにしておきます。

おわりに

この後、Oracle DataBaseのインスタンスの概念やら、SpringBootのJDBCTemplateを使った接続やらでたくさん躓いたので、近いうちに別記事で書こうと思います。

参考にさせていただいた記事など

https://qiita.com/comefigo/items/d05c0e1977cc25e6b98a
https://itedge.stars.ne.jp/docker_image_oracle_database_19c/
https://qiita.com/gorilla0513/items/f22e8cce4e08da031abe

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

Redmine を Docker で Raspberry に入れてみた

この記事は redmine.tokyo 第16回勉強会 の LT で発表した内容を元に書いています。
(LT で喋っていない内容や、振り返って感じたことも含んでいます)

なんで今更?と思われるかもしれませんが、書きかけの記事を下書きに置いてたのをすっかり忘れていました…どうやら写真のアップロードをする途中で力尽きてたようです。
本日、 redmine.tokyo 第17回勉強会 が開催され、その熱気に感動したので、勇気を振り絞って投稿してみようかなと思った次第です。

雑な導入部

皆さんは、プロジェクト管理ツールの Redmine を使っていますでしょうか? 使っているうちにその便利さの虜になって、ビジネス用途だけでなくプライベートでも活用されている方もいらっしゃると思います。
しかし、インターネット上で、たとえばホスティングサービスなどで Redmine を立てて運用していて、うっかり設定を間違えて公開してしまったりしたら、(扱っている情報の種類にもよりますが)プライベートでの込み入った恥ずかしい情報が駄々洩れになっちゃう恐れがあります。とは言え、プライベートネットワーク内でサーバーを用意して、そこに Redmine を立てて運用するとなると、構築の手間や電気代などのランニングコストも馬鹿にならないと思います。
そこで、ふと思いついたのが、「Raspberry Pi で Redmine を立てたら電気代も抑えられるし、Docker なら構築も楽ではないか」というアイディアです。

と、ここまでいかにもそれっぽい理由を書いてみましたが、本音を言えば、単に思いついたから試してみたかっただけだったりもします。

本題

ということで、実際に試した結果を記します。

今回使用した Raspberry Pi

今回は Raspberry Pi Zero W を使用しました。スペック的にギリギリっぽそうで試し甲斐がありそうに感じたのが主な選定理由ですが、もし万一飽きても出費的に痛くないものにしておこうかなという若干後ろ向きな理由もありました。

僕は秋葉原で実物を見て購入しました。今もそうなのかは調べていないのですが、当時(記憶では 2019 年 2 月頃)は単体では売っておらず、スターターキットで購入しました。同じものは Amazon でも入手できるようです。

セットアップ

まず最初におことわりです。セットアップしたのも購入してから間もない時期で、その時は断片的にしか記録をとっていなかった(後で改めて整理しようと思いつつ結局放置していた)ため、記憶を頼りに記述しています。一部、不正確な情報や最新でない情報もあるかと思いますが、ご容赦願います。

ざっくり以下の順に作業しました。とにかく動かすことを優先していたため、本当に必要最小限の手順になっています。

  1. OS のインストール
    • スターターキット付属の SD カードに入っていたインストーラを使用
    • Raspbian Stretch Lite(CUI 環境)をインストール
    • 無線 LAN の設定をしてアップデートをかけた程度
  2. Docker 本体のインストール
  3. Redmine の Docker イメージを取得、起動
    • Raspberry Pi Zero W では arm32v5/redmine のイメージを使用する
      • 実験のため arm32v7 のイメージも試してみたが(案の定)動かなかった
    • 今回は、最も単純な手順でセットアップした
      • Listen するポートだけ 80 番に変えた
      • データベースコンテナもボリュームも使用していない

以下は参考にしたサイトです。

これまで Docker も Raspberry も話には聞いたことはあっても実際に触るのは初めてだったので苦戦するかと思っていましたが、Docker 本体のバグを踏んで原因調査に時間がかかったこと以外は割とあっさりできたのが驚きでした。(Linux はそこそこ触っているので、その経験に助けられている面もありますが)

※ そういえば LT も実際にやるのは初めてでした…

LT で実演したやーつ

現物

現物

モバイルバッテリーで十分動きます。実演時もこれで動かしていました。数時間程度なら全然余裕のようです。
フリスクのケースはサイズ比較用です。本当は、基盤をケースに収納して一笑い取りたかったのですがそこまでネタを仕込む余裕は全然なかったです。一応、現場にもケースを持っていってて、わざと見せようと思ってたりもしたのですが、発表時間削ろうと思ったので割愛しました。(時間押してたのでスベり芸を見せるのもどうかと思って…)

Redmine 画面

Redmine 画面

LT 時は、Redmine 本体に「アタイのまいんちゃん」という名前をつけていました。これは、とある方面で昔お世話になった方から「Juno さんって家でもパソコンばっかイジってそうですね。愛しの Redmine ちゃんとイチャイチャしてるんでしょ?」みたいな感じで軽くディスられた(?)のが僕のツボにハマって、それ以来、自宅で Redmine をセットアップするたびにこの名前をつけています。LT でも「これでいつでもどこでもまいんちゃんと一緒にいられますね!」的なノリで喋ろうかとも思ってたのですが、ドン引きが加速しそうだったので控えておきました…

ちなみに、LT では Raspberry のコンソール画面も映しましたが、ip adocker ps -a の実行結果を出していただけでした。ちゃんと Raspberry 上の Redmine にアクセスしてますよーというのを示したかっただけでした。

今後とりたいアクション

  • データベースコンテナもあわせて動かしたい
  • それなりにまとまった量のチケットなどを作成して性能・リソース使用状況を計測したい
  • Dockerfile を作成して公開したい

LT を振り返って

最初はダダスベりかなとも思っていたのですが、それなりにウケてたようでホッとしています。

以下、Twitter のコメントで気になった話題をピックアップして、僕の見解を書いておきます。

  • SD での運用はデータ消失のリスクがあるから外部ストレージの方がよいというご意見は、まったくもってその通りだなあと思いました。別の案として、データベースコンテナから定期的にデータをダンプをしておいて、クライアント PC 等に転送してバックアップするのでも十分かなとも思いました。そうしておくと、Raspberry 自体に接続する外部装置がなくなり、持ち運びも便利なのかな(そもそも持ち運ぶのかって話はありますが)と思いました。また、データベースのダンプを取っておくと、データベースコンテナ自身のバージョンアップ時に楽じゃないかなとも思いました。いったんデータを消してデータベースコンテナをバージョンアップしてから、ダンプしたファイルでリストアをかけたらうまくいくだろうと楽観的に考えています。
  • 個人用や小規模向けに Raspberry での運用も選択肢に入りうるというのも、十分に考えられます。さらに条件を追加するなら「インターネット上のサービスに機微な情報を置くことに抵抗がある個人または小規模組織」に対しての有力な選択肢になるのかなとも思っています。

おまけ:One more thing 的な話

Unofficial Redmine Cooking の QA #237:Redmineカスタムフィールド表示改善(CF1列表示、項目見出し、表示調整) へのアンサーとなるプラグインを作って OSS で公開したいとお伝えしました。
Redmine view customize plugin (神プラグイン)を使って JavaScript やスタイルシートを埋め込めば実現できることも知っている(というか実際にやっている)のですが、システム管理者じゃないとメンテできないとか、利用者からの要望が増えるにつれてソースコードの管理が煩雑になってきたりとか、いろいろな不都合が予想されます。
それならばいっそのこと独立した機能として切り出して、システム管理者じゃなくても管理者ロールがあればプロジェクト毎に自由にレイアウトをカスタマイズできるようにしてあげるのが良いのではないかと考えています。

と、偉そうに語ってみたのですが、2019 年 11 月現在いまだに何もしていません…本当に申し訳ないです。第17回勉強会で受けたあのものすごい熱量を忘れないうちに今一度やる気を出してがんばりたいと思います。

おわりに

初 LT でとても緊張していたのですが(そうは見えなかったかもですが)、皆さんが生暖かく見守ってくれたおかげでとても楽しむことができました。本当にありがとうございました!
引きこもりに戻りますが、また勇気を振り絞って出てきた際は、お手柔らかにお願いします。

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

Dockerで開発環境構築(Mac + Nginx + PHP-FPM)

Dockerで開発環境構築

この記事はDockerによる開発環境構築(Mac + Nginx + PHP-FPM + MySQL)Part 1をそのまま実行しています。
その中で、分からなかったコードや概念を備忘録として記事にしています。

まずDockerって何よ?

Dockerとは

1,Dockerはミドルウェアのインストールや各種環境設定をコード化して管理します。
2,コード化されたファイルを共有することで、どこでも誰でも同じ環境が作れる。
3,作成した環境を配布しやすい。
4,スクラップ&ビルドが容易にできる。

ふむふむ。
そしてコード化されたファイルを共有することで、どこでも誰でも同じ環境が作れる。このメリットは大きそうだなと思います。
というのも、行きたい企業がDockerを使っていたのでDockerをキャッチアップし出したというだけで、実務というかチー単位では使用したことがないので、大きなメリットを感じられていないのです。

とりあえず進めます。

Dokerはインストールできている前提で進めます。

コンテナとイメージって何よ?

イメージ・・・ファイル
コンテナ・・・イメージを実行したもの

といったざっくりした認識でございます。
間違っていたら教えてください。

なので、コンテナを実行するにはイメージが必要です。
欲しいイメージがないときはDocker hubからpullしてきましょう。
$ docker pull centos
これでCentosがpullされます。

少し話は飛びますが
$ docker images$ brew listは似ているな〜と感じます。

さて本題

さて本題に入ります。

nginxコンテナ作成

お好きなディレクトリに移動して以下のコマンドを入力。
目に見えた方がわかりやすいので僕はDesktop上で行いました。

$ mkdir docker
$ cd docker
$ docker container run -d -p 8000:80 --name web nginx:latest

こちらがコンテナを作成する際のコマンドです。
docker container run -d -p 8000:80 --name web nginx:latest

-d・・・バックグラウンドでDockerコンテナを実行
-p・・・ポート指定
n--ame・・・コンテナに名前をつける

と言った感じです。

$docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
dde74e29d594        nginx:latest        "nginx -g 'daemon of…"   9 seconds ago       Up 7 seconds        0.0.0.0:8000->80/tcp   web

コンテナが作成されプロセスが立ち上がったのが分かります。

http://localhost:8000/
にアクセスしてNginxの画面が表示されていれば成功です。

とりあえず確認できたら止めておきます。

$ docker container stop web

次ーーー。

docker-composeでnginxサーバーを起動

nginxを起動できましたが、phpを扱うとなるとphp-fpmのコンテナも作成しなくてはいけません。
※立ち上げる順番も気にしないといけないそうな・・・

そこで、コンテナ同士の依存関係をyml形式のファイルで管理できるdocker-composeというものを使用します。
先ほど作成したディレクトリ内で、docker-compose.ymlを作成します。

$ vi docker-compose.yml
docker-compose.yml
version: '3'             #フォーマットのバージョン。現在は3が最新。
services:                #アプリケーションを動かせるための記述
  web:                   #コンテナ名
    image: nginx:latest  #イメージ名
    ports:               #使用ポート
      - "8000:80"

記述後にnginxを起動させます。

$ docker-compose up -d

http://localhost:8000/
アクセスして、nginxの画面が出れば成功。

$一旦ストップさせます。

$ docker-compose stop

Hello World!!

次はDockerでHello Worldを表示させます。

$ mkdir src
$ cd src
$ vi index.html
<h1>Hello World !!</h1>

次は設定ファイルを記述します。

$ cd ../
$ mkdir web
$ cd web
$ vi default.conf

nginxの設定をdefault.confに記述していきます。

default.conf
server {
    listen 80;

    root  /var/www/;
    index index.html;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;
}

その後、docker-compose.ymlの最終行にこちらを追記します。

docker-compose.yml
#version: '3'
#services:
#  webserver:
#    image: nginx:latest
#    ports:
#      - "8000:80"
    volumes: #以下を追記 [ホストのファイルパス]:[コンテナファイルパス]
      - ./webserver/default.conf:/etc/nginx/conf.d/default.conf
      - ./src:/var/www/

volumesは、ホストのファイルパスをコンテナのファイルパスへマウントします。
つまり、コンテナ側の/etc/nginx/conf.d/default.confはホスト側の./webserver/default.confを認識するようなります。
マウントすることによって、コンテナ内で変更した内容を、ホスト側にリアルタイムで同期することができます。

再びdockerを立ち上げます。

$ docker-compose up -d

http://localhost:8000/
アクセスして、Hello Worldが表示されれば成功。

$一旦ストップさせます。

$ docker-compose stop

PHPを動作させるAPサーバーの設定

phpを扱うためにはAPサーバーが必要です。

docker-compose.ymlを編集します。

docker-compose.yml
#version: '3' 
#services:
#  web:
#    image: nginx:latest
#    ports:
#      - "8000:80"
    depends_on: #追記
      - app
#    volumes:
#      - ./web/default.conf:/etc/nginx/conf.d/default.conf
#      - ./src:/var/www/
  app: #以下を追記
    image: php:7.2.15-fpm
    volumes:
        - ./src:/var/www/

depends_onで依存関係を設定します。
これを設定しないとphpは動きません。

次にdefault.confを編集します。

default.conf
#server {
#    listen 80;
#    root  /var/www/;
#    index index.php index.html;
#    access_log /var/log/nginx/access.log;
#    error_log  /var/log/nginx/error.log;
    location / { #以下を追記
        try_files $uri $uri/ /index.php$is_args$args;
    }
    location ~ \.php$ {
          fastcgi_split_path_info ^(.+\.php)(/.+)$;
          fastcgi_pass   app:9000;
          fastcgi_index  index.php;
          include        fastcgi_params;
          fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
          fastcgi_param  PATH_INFO $fastcgi_path_info;
      }
#}

その後srcに移動しindex.phpを作成し中にphpinfo();を記述します。

index.php
<?php

phpinfo();

?>

再びdockerを立ち上げます。

$ docker-compose up -d

http://localhost:8000/
アクセスして、PHPの設定情報が表示されればOKです。

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

Docker for macのゴミデータを削除したら20GBの容量を取り戻すことができた

docker使っているだけで、どんどんゴミデータ溜まっていく問題

タグなしimage削除

docker images -qf dangling=true | xargs docker rmi

起動していないコンテナ削除

docker ps -aqf status=exited | xargs docker rm -v

紐付いていないデータボリューム削除

docker volume ls -qf dangling=true | xargs docker volume rm

disk image sizeの見直し

これをやると全てのimage, containerが消えるので注意

preference→disk→Disk image sizeを良い感じに下げる
スクリーンショット 2019-11-02 18.52.40.png

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

GithubとJenkinsを連携させるにあたり、Github webhookの設定でつまずいたのでまとめておく

はじめに

GithubとJenkinsを連携させるにあたり、Github webhookの設定でつまずいたのでまとめました。
今回はgit pushをトリガーとするべく、github webhookの設定から行っていましたが、ジョブが実行されないときがあったので、jenkinsでポーリングして行う方法のほうがいいかもしれません。

そこで本記事では、Githubのwebhookを使う場合の設定とjenkinsでポーリングして行う場合の設定の2つをご紹介します。

なお、jenkins自体のインストール、slackのプラグインはメモ程度に最後に書いておきます。

全体の構成

Screenshot from 2019-11-03 11-07-20.png

環境/バージョン情報

  • AWS (EC2, VPC, EIP, etc)
    • Ubuntu 18.04.3 LTS
  • Jenkins ver. 2.190.2

どちらでも必要な設定

Github pluginのインストール

  • トップ画面からManage Jenkins >> Manage Plugins >> Availableの順にクリック  (URL: http://\${JENKINS_IP}:8080)
  • filterの検索窓に github と打ち込んで検索し、Github pluginをインストールして再起動
  • jenkinsの管理画面が戻らない場合は、http://\${JENKINS_IP}:8080/restart とタブに打ち込む
  • 管理画面にログインできたら、Availableの右隣のInstalledをクリックした後、githubと検索するとインストールされていることが確認できる Screenshot from 2019-11-02 17-47-22.png

鍵とssh-agentの設定

  • 秘密鍵のファイル名は~/.ssh/id_rsa、パスフレーズは無しとした
ubuntu@ip:~$ sudo su - jenkins
jenkins@ip:~$pwd
/var/lib/jenkins
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
> Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]
> Enter passphrase (empty for no passphrase): [Type a passphrase]
> Enter same passphrase again: [Type passphrase again]

- 秘密鍵と公開鍵はコピーし、任意のテキストに貼り付けておく

jenkins@ip:~$ sudo cat /.ssh/id_rsa
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
jenkins@ip:~$ sudo cat /.ssh/id_rsa.pub
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

  • 鍵を生成した後、ssh-agentに鍵を追加
jenkins@ip:~$ eval "$(ssh-agent -s)"
> Agent pid 59566
jenkins@ip:~$ ssh-add ~/.ssh/id_rsa
  • ~/.ssh/configを作成
jenkins@ip:~$ cat ~/.ssh/config 
Host github github.com
  HostName github.com
  User git
  Port 22
  IdentityFile /var/lib/jenkins/.ssh/id_rsa
  • githubにsshで接続
  • このように出力されれば成功です。 but以下は、shellでの接続はgithubでは提供されていないということなので、今回は無視で大丈夫です。
$ ssh -T git@github.com
Hi jenkins-hogehogehoge! You've successfully authenticated, but GitHub does not provide shell access.
  • githubからjenkinsサーバーへgit pullするアカウント用にgithubアカウントを開設し、先ほどコピーした公開鍵を登録しておく

ジョブの設定

  • トップ画面画面からNew Item をクリック
  • Enter an item name にお好きなジョブ名を記載
  • Freestyle project をクリックした後、OKをクリック。
  • GitHub projectProject urlに✔を入れる job_key0.png
  • githubのリポジトリをHTTPSでクローンするときのURLをコピーし、ペースト
  • Source Code Managementまでスクロールし、Gitに✔を入れる
  • Repositories付近のRepository URLにはSSHでクローンするときのURLをペースト Screenshot from 2019-11-02 17-56-16.png
  • Credintialsの右となりのAddをクリックし、出てきたポップアップの項目にはそれぞれ以下を選択、あるいは入力
項目
Kind SSH Username with private key
Usernmae jenkins
Key 先ほどコピーした~秘密鍵      

※秘密鍵を入力するには、Private Keyの隣のEnter directlyをクリックすることが必要です。

  • ポップアップ画面左下のAddをクリック

job_key.png

  • Credintialsのところにjenkinsと入っていればOKです。
  • Branches to buildの右隣のBranch Specifier (blank for 'any')にはジョブを実行したいブランチ名、あるいはその一部を記載 job_key1.png
  • Build Triggersまで下にスクロールし、GitHub hook trigger for GITScm pollingをクリック
  • Buildの箇所まで下にスクロールし、Add build step >> Execute shellの順番にクリックし、実行したいコマンドを入力
  • 僕が今回使ったリポジトリをそのまま使う場合はこんなかんじです。 flask-docker
git checkout master
git fetch
git merge origin/master
ls
pwd
bash /var/lib/jenkins/workspace/githubWebhook/sh/setup.sh
bash /var/lib/jenkins/workspace/githubWebhook/sh/curlHttp.sh

jenkins2.png

※ファイル名はフルパス、 シェルスクリプトを使う際にはbash /path/filenameのようにする

githubのwebhookを使う場合の設定

項目
Payload URL http://\${JENKINS_IP}:8080/github-webhook/
Content type application/x-www-form-urlencoded (デフォルトのまま)
Secret 設定せず
Which events would you like to trigger this webhook? お好きなものを選択
Active ✔をつけたまま

Payload URLの書式

Jenkinsの公式ドキュメントに記載されている、$JENKINS_BASE_URL/github-webhook/を使うようにしてください。

In this mode, you'll be responsible for registering the hook URLs to GitHub. Click the (question) icon (under Manage Jenkins > Configure System > GitHub) to see the URL in Jenkins that receives the post-commit POSTs — but in general the URL is of the form $JENKINS_BASE_URL/github-webhook/ — for example: https://ci.example.com/jenkins/github-webhook/.

出所: GitHub Plugin - Jenkins - Jenkins Wiki

冒頭でお話しましたが、webhookが機能せず、ジョブが実行されないことがありました。
そこでjenkinsのジョブの設定でポーリングするように設定するように変更したので、変更箇所を書いていきます。

jenkinsのジョブの設定でポーリングすることでgithubと連携させる場合、githubのwebhookよりジョブの実行が遅くなることがデメリットです。。。

jenkinsでポーリングして行う場合の設定

  • Build TriggersGitHub hook trigger for GITScm pollingから✔を外し、代わりにPoll SCMに✔をつける
  • githubのwebhookの設定を解除
  • Scheduleの右隣りの枠にCronで設定するように記載。

これだけです。

Screenshot from 2019-11-02 20-32-56.png

結果の確認方法

  • 管理画面から確認したいジョブ名をクリック

Screenshot from 2019-11-02 21-01-16.png

  • 確認したいジョブの番号(直近の場合は一番大きい数字)をクリック

Screenshot from 2019-11-02 21-01-41.png

  • Console Outputをクリック Screenshot from 2019-11-02 21-02-14.png
  • 末尾にFinished: SUCCESSと出力されていればジョブは成功しています。

Screenshot from 2019-11-02 21-08-19.png

Screenshot from 2019-11-02 21-08-34.png

Jenkinsのインストール方法(Ubuntu, 18.04 LTS, EC2)

- 以下に記載するコマンドを実行

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt update -y
$ sudo apt-get install openjdk-8-jdk
$ whereis java
/usr/bin/java
$ tail ~/.bashrc
#追加で記載
export JAVA_HOME=/usr/bin/java
export PATH=$JAVA_HOME/bin:$PATH
$ sudo apt update -y
$ sudo apt upgrade -y
$ sudo apt install jenkins -y
$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword
aaaaaaaaaaaaaaaaaaaaaaaa  #管理画面からログインするための初期パスワード
  • http://\${JENKINS_IP}:8080を開いて上のパスワードを入力
  • インストールプランは Install suggested pluginsを選択

Slackプラグインのインストール方法

Github pluginと同じく、Availableからslackと検索し、インストールした後、リスタートするだけです。

最後に

最後に今回Jenkinsで扱ったリポジトリはこちらです。
flask-docker
Dockerコンテナ上にflaskとnginxとuwsgiを使ってwebアプリを立ち上げるというものです。

こちらのリポジトリでは、
jenkinsをDockerでMasterとSlaveの2つを立ち上げるまでをハンズオン形式でご紹介しているので、どうぞ。

※sudoをパスワード無しでするようにしています。(sudo脆弱性、、。)

ubuntu@ip:~$ sudo visudo
# 追加
jenkins ALL=NOPASSWD: ALL

参考
- ssh key
Generating a new SSH key and adding it to the ssh-agent
- jenkinsの初期設定が終わってから、あるいはプラグインをインストールした後、管理画面が真っ白になったままの場合
Jenkins - Setup wizard blank?
- Github webhook Payload URLの書式
GitHub Plugin - Jenkins - Jenkins Wiki

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

#docker コンテナでコマンド履歴を保存したいけど出来ないので #Mac 開発なら #Alfred のクリップボード拡張はいかが?

代替利用。いったんコマンドをクリップボード履歴に入れておいて、MacOsからコマンドをコピペする。

image

誤操作のペーストが怖いので利用は開発環境にだけにととどめておいたほうが良いかもね。

iTerm2 なら

Command+Shift+C -> 範囲選択して Y

のコピー機能も重宝する。

image

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/2653

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

【OCI】Archive Storageを利用して低コストでバックアップを保管する。

はじめに

OCIを操作するOracle Cloud Command Line Interface(OCI CLI)の実行環境を用意する。
なるべく環境を汚したくない&バージョンアップ楽にしたいタイプなのでDockerで用意します。

今回利用したDocker環境はGit hubで公開しています。
manaki-naoe/docker-oci-cli
【OCI】DockerでOCI-CLIを実行する。

アーカイブストレージについて

AWSでいう「Amazon S3 Glacier」
GCPでいう「Nearline Storage/Coldline Storage」にあたるサービスだと思っています。

低頻度アクセス向けのストレージ
1か月あたりGB 0.312円
データアクセスや最小オブジェクトサイズなど隠れたコストが無いため、
コスト計算ができ安全に利用できると思います。

復元まで
データの復元には約4時間ほどかかるそうです。

料金について

AWSやGCPでは取り出すために料金がものすごくかかってしまいますが、
OCIではストレージ料金とリクエスト費用しかかかりません。
0.jpg
画像参照先

Always Freeもあります

10GBのオブジェクト・ストレージ
10GBのアーカイブ・ストレージ

10GBまでが無料になっています。

準備

アーカイブストレージを作成する。

ダッシュボードからオブジェクト・ストレージを選択
1.jpg

バケットの作成をクリック
2.jpg

アーカイブストレージを利用する場合は必ずストレージ層を「アーカイブ」にしてください。
3.jpg

作成され終了です。
4.jpg

OCI CLIの実行環境を用意する。

Dockerfileをクローンする

$ git clone git@github.com:manaki-naoe/docker-oci-cli.git

イメージのビルド

$ docker build -t oci-cli .

ConfigファイルとAPI Keyの作成

$ docker run --rm -v ${PWD}/.oci:/root/.oci -it oci-cli:latest setup config

作成したAPI Keyの登録
ユーザーの詳細画面でAPI Keyを追加してください

5.jpg

コンパートメント用configの作成

$ docker run --rm -v ${PWD}/.oci:/root/.oci -it oci-cli:latest setup oci-cli-rc

# リポジトリ内はこんな構造になっているはずです。
- .oci
   - config
   - oci_api_key.pem
   - oci_api_key_public.pem
   - oci_cli_rc
- Dockerfile

$ vi .oci/oci_cli_rc
# 末尾に以下を追加します。
[DEFAULT]
compartment-id = <Compartment OCID>

以上で準備は終了です。

アーカイブストレージにアップロードする。

1ファイルだけアップロードする。

スクリプトを設置する

put.sh
#!/bin/bash
docker run --rm \
-v ${PWD}/.oci:/root/.oci \
-v <アップロードしたいファイルがあるディレクトリパス>:/root/bucket \
-it oci-cli:latest \
os object put \
--bucket-name <バケット名> \
--file /root/bucket/$1

実行

$ ./put.sh <ファイル名>

オブジェクト・ストレージの詳細ページでファイルがアップロードされていれば成功です。

ディレクトリ内のファイルをアップロードする。

スクリプトを設置する

bulk_upload.sh
#!/bin/bash
docker run --rm \
-v ${PWD}/.oci:/root/.oci \
-v <アップロードしたいファイルがあるディレクトリパス>:/root/bucket \
-it oci-cli:latest \
os object bulk-upload \
--bucket-name <バケット名> \
--src-dir /root/bucket \
--exclude .gitignore \
--no-overwrite

除外したファイルがあれば[--exclude]オプションで除外できます
例 --exclude .gitignore

--no-overwriteはすでに存在しているファイルをアップロードしないオプションです。

実行

$ ./bulk_upload.sh

オブジェクト・ストレージの詳細ページでファイルがアップロードされていれば成功です。

おわりに

コストの事前計算ができ、
取り出すための料金がリクエスト費用しかないため、
安心して取り出すことができます。

10GBまで無料でもあるので、
私はバックアップの保管に利用しています。

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

HTTPSに対応したWordPressのローカル開発環境をDockerで構築

はじめに

WebサイトのHTTPS対応が必須な昨今、ローカルでWordPressのテーマ開発をするときもHTTPSに対応しておきたいですよね。
そんな環境をDockerを使ってサクッと構築する術をご紹介します。
オレオレ証明書の発行を頑張る必要もないので、比較的楽にできると思います。

概要

※最新のWordPressを用いてイチから開発、もしくは移行プラグイン(All-in-One WP Migrationなど)を用いて既存のWordPressをローカルへ持ってきて開発することを想定しています。

筆者の動作環境

  • macOS Mojave 10.14.6
  • Docker for Mac 2.1.0.4
  • Homebrew 2.1.15
  • Chrome 78.0.3904.70
  • Firefox 70.0

※Docker Desktop、Homebrewが導入済みであることを前提に進めます。

手順

作業ディレクトリへ移動し、以下のようなディレクトリとファイルを作成します。

.
├── certs
├── php
│   └── php.ini
├── src
└── docker-compose.yml

docker-compose.ymlは公式のコードを少し書き換えたものを用意します。

docker-compose.yml
version: '3.3'

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      - ./src:/var/www/html 
      - ./certs:/etc/ssl/private
      - ./php/php.ini:/usr/local/etc/php/conf.d/php.ini
    ports:
      - "80:80"
      - "443:443"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
volumes:
  db_data: {}
  • 443ポートの割り当て
  • 証明書を入れる予定のcertsと、phpの設定を上書きするphp.iniのマウント

を追記しています。

docker-compose up -dでコンテナを起動すれば、WordPressを使うことができます。
http://localhost もしくは http://127.0.0.1 をブラウザで叩いて、Wordpressのインストール画面に遷移することを確認してください。

それでは、本題のhttps対応部分にいきましょう。
一旦、docker-compose stopでコンテナを停止しておいてください。

mkcertで証明書を発行

以下、macOSでの導入方法です。他のOSの場合はmkcertのリポジトリを参照ください。
まずはmkcertをインストールします。

brew install mkcert
brew install nss
mkcert -install

以下のようなログが出ることを確認してください。

Using the local CA at "[your_specific_path]" ✨
The local CA is now installed in the Firefox trust store (requires browser restart)! ?

次に、作業ディレクトリからcertsディレクトリへ移動(cd certs)し、証明書を発行します。

mkcert localhost 127.0.0.1
Using the local CA at "[your_specific_path]" ✨

Created a new certificate valid for the following names ?
 - "localhost"
 - "127.0.0.1"

The certificate is at "./localhost+1.pem" and the key at "./localhost+1-key.pem" ✅

たったこれだけで証明書が発行できてしまいます。mkcert、便利すぎですね:slight_smile:

この証明書を、先ほどのWordpressコンテナに適応させてあげましょう。
再度docker-compose up -dでコンテナを立ち上げ、コンテナの中に入ります。

docker exec -it [your_container_name] /bin/bash

[your_container_name]部分は、docker-compose psなどで確認できます。

コンテナの中に入ったら、先ほど発行した証明書がマウントされていることを確認してみます。

root@5a6f0bfa2cf8:/var/www/html# ls -al /etc/ssl/private
total 12
drwxr-xr-x 4 root root  128 Oct 31 02:59 .
drwxr-xr-x 4 root root 4096 Sep 12 09:32 ..
-rw------- 1 root root 1708 Oct 31 02:59 localhost+1-key.pem
-rw-r--r-- 1 root root 1647 Oct 31 02:59 localhost+1.pem

次にSSLの設定ファイルを編集するのですが、その前にエディタをインストールしましょう。

apt-get update
apt-get install vim

お気づきかと思いますが、Wordpressの公式イメージ、Debianなんですね。

root@5a6f0bfa2cf8:/var/www/html# cat /etc/issue
Debian GNU/Linux 10 \n \l

コンテナ内で色々やる際には留意しておいていただけると。

エディタがインストールできたら、設定ファイルを編集していきます。

vi /etc/apache2/sites-available/default-ssl.conf

# 32, 33行目を編集
SSLCertificateFile /etc/ssl/private/localhost+1.pem
SSLCertificateKeyFile /etc/ssl/private/localhost+1-key.pem

編集が完了したら、a2ensite default-ssla2enmod sslコマンドで反映します。

root@5a6f0bfa2cf8:/var/www/html# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  service apache2 reload

root@5a6f0bfa2cf8:/var/www/html# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  service apache2 restart

コンテナからexitし、最後にdocker-compose restartなどでapache2を再起動すれば完了です。
https://localhost もしくは https://127.0.0.1 をブラウザで叩いてみましょう。
スクリーンショット 2019-11-02 13.52.02.png
無事Wordpressのインストール画面に遷移できたでしょうか?

後はタイムゾーンや言語を変更したり、お好みでphpMyAdminのコンテナを用意したりして、環境を整えていただければと思います。

おまけ

All-in-One WP Migrationなどでローカルへ移行する場合、最大アップロードファイルサイズで引っかかることがあると思います。
用意したphp.iniファイルに以下を追記して、制限を解除しましょう。

php.ini
post_max_size = 20M
upload_max_filesize = 20M

その他phpの言語設定等も、こちらに記述すればOKです。

以上、お読みいただきありがとうございました。
参考になれば幸いです。

参考

数分でできる!mkcertでローカル環境へのSSL証明書設定
Debian 8 Jessie : Apache2 : SSLの設定 : Server World

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

dockerのコンテナのrootユーザを、ホストOSの一般ユーザにマッピングする方法

dockerのコンテナのrootユーザを、ホストOSの一般ユーザにマッピングする方法

Linuxではコンテナで作成したファイルなどはホスト側ではrootユーザでしか扱えないため、ファイルをマウントして開発する場合はいちいちroot権限で書き込みする必要があります。
ホスト側の一般ユーザを、新しくコンテナの一般ユーザとして作ることもできますが、コンテナ側でroot権限が使えたほうが良い場合が多いです。
そこで、ホスト側の一般ユーザのuidとgidを、コンテナのrootユーザにマッピングしてしまえば、楽です。

 環境

Ubuntu 18.04.3 LTS

方法

まず、自分のIDを確認します。

$id username
uid=1000(username) gid=1000(username) groups=1000(username),...

usernameのところは各々のユーザー名が表示されていると思います。

次に、/etc 内の subuid と subgid ファイルに以下のように書き込みます。
usernameのところは自分のものを書いてください

subuid,subgid
username:1000:65536

なければ新しく作り、二つとも同じように記述してください。
次に、/etc/docker 内の daemon.json に次のように記述してください。ファイルはなければ作ってください。

daemon.json
{
    “userns-remap”:”username”
}

そして

service docker restart

でDockerを再起動したら完了です。

参考

Code Example Docker 17 - Isolate containers with a user namespace

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

Rails on DockerのQuickstartをalpine linuxでやってみる

Abstract

Rails on DockerはDocker docsにサンプルアプリが載っています。
--> Quickstart: Compose and Rails | Docker Documentation

ただ、Dockerイメージはサイズを軽量化するのがよしとされており、そのためにalpine linuxを使うというのはよくある話のようです。ので、上記のQuickstartをalpineで実施するメモです。

Define the project

まず、Dockerfileを作ります。Quickstartでは以下の内容。

Dockerfile(Quickstart版)
FROM ruby:2.5
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
COPY . /myapp

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# Start the main process.
CMD ["rails", "server", "-b", "0.0.0.0"]

これをalpine化するには、ベースのイメージとしてalpineを選択すればOKです。
Dockerhubのrubyイメージから最新の物を探しましょう。最新・安定のruby-alpineイメージにはalpineタグがついています。
FROM ruby:alpineと宣言してもいいのですが、この場合はビルドのタイミングでバージョン変わっちゃう可能性あるのでその時のバージョンを指定するといいと思います。2019/11/01時点では2.6.5-alpine3.10

また、alpine linuxではapt-get installは使えず、apk addを使います。必要なパッケージもちょっと違います。そこら辺に気をつけて以下のようなDockerfileを作ります。

Dockerfile(Quickstartをそのままalpine化してみた)
FROM ruby:2.6.5-alpine3.10
RUN apk update && \
    apk upgrade && \
    apk add --no-cache linux-headers libxml2-dev make gcc libc-dev nodejs tzdata postgresql-dev postgresql && \
    apk add --virtual build-packages --no-cache build-base curl-dev
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
RUN apk del build-packages
COPY . /myapp

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# Start the main process.
CMD ["rails", "server", "-b", "0.0.0.0"]

alpine linuxは軽量のため、色々とRailsアプリを実行するのに足りないパッケージとかがありますのでそれらをapk addしています。
build-basecurl-devについては、--virtualオプションでbuild-packagesという名前をつけて、bundle install後にapk del build-packagesで削除してます。これらはRailsアプリのビルド時にのみ必要(実行時は不要)なパッケージなので削除することでDockerイメージを軽量に保つようにしてます。

さらに、Rails5.2以降はcredentialsで秘匿情報を管理するようになりますが、これを編集するためにはeditorのパッケージがインストールされている必要があります。のでvimを入れときます。
Rails6からはwebpackerが採用されているためyarnが必要です(QuickstartはRails5が対象でしたが、Rails6リリースされたのでそちらに合わせます)。これも追加します。
また、文字コードやタイムゾーン、インストールパッケージを環境変数として管理するともうちょっと可読性が上がりそうです。
WORKDIRは実はmkdirも兼ねるのでそこらへんも省略したい。
最終的に以下のようなDockerfileでいかがでしょうか?

Dockerfile(alpine化最終版)
FROM ruby:2.6.5-alpine3.10

ENV RUNTIME_PACKAGES="linux-headers libxml2-dev make gcc libc-dev nodejs tzdata postgresql-dev postgresql yarn vim" \
    BUILD_PACKAGES="build-base curl-dev" \
    ROOT="/myapp" \
    LANG=C.UTF-8 \
    TZ=Asia/Tokyo

WORKDIR ${ROOT}
COPY Gemfile ${ROOT}
COPY Gemfile.lock ${ROOT}

RUN apk update && \
    apk upgrade && \
    apk add --no-cache ${RUNTIME_PACKAGES} && \
    apk add --virtual build-packages --no-cache ${BUILD_PACKAGES} && \
    bundle install && \
    apk del build-packages

COPY . ${ROOT}

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# Start the main process.
CMD ["rails", "server", "-b", "0.0.0.0"]

続いてGemfileを作成します。現在のRailsの最新バージョンは6ですので、そこだけQuickstartの内容とは異なりますが、基本一緒です。

Gemfile
source 'https://rubygems.org'
gem 'rails', '~>6'

また、Quickstartと同様にGemfile.lockの空ファイルを作成しておきます。

$ touch Gemfile.lock

続いて、server.pid問題を解決するためのentrypoint.shを作成します。これもQuickstartの内容と一緒ですが、alpine linuxではbashではなくashが使われているところに違いがあります。(shebangが#!/bin/sh

entrypoint.sh
#!/bin/sh
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f /myapp/tmp/pids/server.pid

# Then exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"

最後にdocker-compose.ymlを記載します。ここもalpineを使っているのでbashではなくashを使います。
せっかくなので、postgresqlもalpineのイメージを使っています。postgres - Docker Hub
またpostgresqlのタイムゾーンをDockerfileと合わせておくのもよしです。

docker-compose.yml
version: '3'

services:
  db:
    image: postgres:12.0-alpine
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
    environment:
      - TZ=Asia/Tokyo

  web:
    build: .
    command: ash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db

Build the project

ここまで作ったファイルは全てRailsアプリのルートディレクトリとなるディレクトリに格納してある前提です。
Railsアプリを新規作成するために、そのルートディレクトリで以下のコマンドを実行します。

$ docker-compose run --rm --no-deps web rails new . -fT -d postgresql

Quickstartと少し違うポイントはalpineだからとかでなく趣味ですスミマセン。

  • --rm:実行完了後コンテナが削除される。ゴミ掃除。
  • --no-deps:リンクしているサービス(今の場合はdb)を起動しない。docker-composeのオプションなので、この位置が正しいのではないだろうか...
  • -f--forceと同じです。ファイルをオーバーライドします。(Gemfile, Gemfile.lock)
  • -T:テスト系のファイル作成をスキップ。RSpecを使うことが多いので。
  • -d postgresql--database=postgresqlと同じです。

rails newが完了したらDockerイメージをビルドします。

$ docker-compose build

Connect the database

ここはまるパクリですね。

config/database.yml
default: &default
  adapter: postgresql
  encoding: unicode
  host: db            #追加
  username: postgres  #追加
  password:           #追加
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

データベースが作成してコンテナを立ち上げます。

$ docker-compose run --rm web rails db:create
$ docker-compose up

あ、コンテナをバックグラウンドで実行したい場合は-dオプションです。

$ docker-compose up -d

View the Rails welcome page!

ブラウザでhttp://localhost:3000にアクセスすればQuickstart同様、RailsのWelcome pageが表示されるはずです。

image.png

Stop the application

アプリのストップは以下のコマンドで。

$ docker-compose down

Hello world with scaffold

ここまでだとデータベースがちゃんと使えているのかHello worldできていないので、ちゃちゃっとscaffoldでそこまで確認します。確認のためだけなので、name属性をもつUserモデルで。

$ docker-compose run --rm web rails g scaffold user name:string

マイグレーションファイルが作成されるので、db:migrateを実行します。

$ docker-compose run --rm web rails db:migrate

さらにルートパスをusers#indexのページにしておきます。

rb;config/routes.rb
Rails.application.routes.draw do
  resources :users #scaffildで自動追加されている

  # 以下を追加
  root to: 'users#index'
end

これでコンテナを起動すると、ルートパスが以下の画面に変わっていて、scaffoldでCRUDできるようになっているはず。
image.png

docker-compose.ymlでpostgresqlのデータをtmp/dbとマウントしているのでコンテナを停止再起動したりしてもデータは消えません。

Conclusion

Rails on DockerのQuickstartをalpine linuxベースで実施してみました。
Dockerfileで多少の違いが、特にパッケージ系は違いがありますが、buildしてしまえば差は無いように感じます。
サイズの比較はしてないですが、いろいろな方の調査結果ではrubyruby-alpineではイメージサイズが数倍〜十数倍違ったりするらしいので、アップロードダウンロードやディスクにとってメリットがあるのでオススメです。

Reference

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