Dockerでapacheサーバーを立ててphpでHello worldするまで

Django+PostgreSQLの環境を作る予定だったけど先日、３年くらい前から憧れていた札幌の企業に
エントリーしたらPHPでの実技試験があるとのことだったので、予習をすることに

今回はその第一弾としてphpの開発環境(DBなし)までやっていこうと思う。

まずはindex.phpの用意
ファイルはカレントディレクトリに作る

<?php
<!-- index.php -->
<?php
echo 'Hello world!!';

Hello Worldするだけなのでとても簡単

次はDockerfileの作成

作らなくてもできるけどindex.phpを毎度コピーするのは面倒なので作る
なんとDockerには最初からphpとapacheがセットになった公式イメージがあるので
今回も目的はとても簡単に達成できる
hub.docker.com

# Dockerfile
FROM php:7.2-apache
LABEL maintainer="carametal"
COPY ./ /var/www/html/

今回はmaintainerを設定してみた
maintainerはだれが管理しているimageなのかを示すラベルで
個人開発だし世の中に出すわけじゃないけどお試し

COPY命令でカレントディレクトリをコンテナの/var/www/htmlにコピーすることで
カレントディレクトリのindex.phpとDockerfileが/var/www/html配下にコピーされる

apacheは「IPアドレス/」へのアクセスに対して/var/www/html/index.phpをデフォルトで実行するので
これでOK

あとはビルドして実行する

docker build -t php7.2-apache .
docker container run --rm -d -p 8000:80 --name php-test php7.2-apache

これでhttp://localhost:8000/にアクセスするとHello world!!と表示される

次回はMySQLを入れて簡単なDBアクセスを実行するところまでやっ見る予定

Dockerを使ってcentosコンテナ内にnginxサーバーをたてる

前回はdockerでnginx環境を立てたので今回は一歩進めてcentosコンテナ内にnginxを立ててみようと思う

前回の記事はこちら
carametal.hatenablog.com

そして今回はこちらの記事を参考にさせていただきました
qiita.com

前回はdockerでnginxコンテナを実行するだけで良かったけど今回は
centosコンテナの中にnginxサーバーをたてるのでコンテナを実行するだけでは実現できない

centosコンテナを実行してコンテナ内に入ってコマンドを叩くだけでも良いが
Dockerを使うのであれば簡単に環境を作り直せるようにDockerfileを使っていく

結論から言うと

カレントディレクトリに以下のようなDockerfileを作り

FROM centos:8
RUN /bin/sh -c 'yum install -y nginx'
CMD ["nginx", "-g", "daemon off;"]

以下のコマンドを流すだけでcentosコンテナ内にnginxサーバーをたてることができて
http://localhost:9000/ にアクセスするとnginxのテストページが表示されるようになる

docker build -t centos-nginx .
docker container run -d --rm -p 9000:80 --name test-centos-nginx centos-nginx

せっかくなので掘り下げてみる

まずはDockerfileについて

FROM centos:8

ではFROM命令を使って使用するイメージを指定する
FROM命令はDockerfile内で一番最初に書く必要がある(コメントを除く)
今回はcentosコンテナを利用するためcentosを指定し、現在の最新版であるcentos8を使用するため
オプションでタグを指定してcentos:8とした

RUN /bin/sh -c 'yum install -y nginx'

ではRUN命令を使ってnginxをcentos内にインストールしている
RUN命令はシェル形式とexec形式と呼ばれる２つの形式があり今回使用しているのはシェル形式と呼ばれている方
「/bin/sh/ -c」の部分でシェルスクリプトを実行する用のインタプリタを指定
あとに続く「yum install -y nginx」でnginxのインストールを実行している
yumはRed Had系のLinuxディストリビュージョンで使用されるパッケージ管理コマンドのひとつ
Ubuntuでいうとapt-getに当たるもの、-yオプションはインストール時の質問（yes/no）をすべれyesにしてくれる便利なオプション

RUN命令をシェル形式で実行する場合、インタプリタの指定は「/bin/sh -c」がデフォルトで設定されているため

RUN yum install -y nginx

のように省略できる。

ちなみにexec形式で今回のRUN命令を書くと以下のようになる

RUN ["/bin/sh", "-c", "yum install -y nginx"]

最後の

CMD ["nginx", "-g", "daemon off;"]

ではCMD命令を使ってnginxサーバーを起動している
RUN命令はシャル形式exec形式のどちらでも良いようだがCMD命令はexec形式が推奨されているので
exec形式を使用している
docs.docker.jp

パラメータで渡している「-g」はグローバル設定ディレクトリというものを指定するためのオプションで
「daemon off;」はその引数になり、nginxがデーモンになるべきか(バックグラウンドで動くべきか)どうかを
指定している今回は「off」にしているのでnginxはフォアグラウンドで動く

なぜこんなものを指定しているのかというと
nginxを動かすだけなら「nginx」コマンドで事足りるのだが
Dockerコンテナ内で動かす際はフォアグラウンドで動かしていないと
コンテナ自体が即座に終了してしまうらしい
以下の記事が参考になりました

qiita.com

実際にDockerfileを

FROM centos:8
RUN yum install -y nginx
CMD ["nginx"]

として

docker build -t centos-nginx-damon-on .
docker container run -d --rm -p 9000:80 --name test-centos-nginx centos-nginx

のようにコマンドを流してみたところ
正常にコンテナが生成されるものの

docker container ps

で実行中のコンテナを確認してもtest-centos-nginxは一覧になく
コンテナが終了してしまったいることが確認できた

ひとまず目的である「centosコンテナ内にnginxサーバーをたてる」が達成できたので
今日はこんなところで終了

この調子でDjango+PostgreSQL環境を作っていきたい

nginxのDockerコンテナを立てるまで

docker container run -d -p 8000:80 --name test_nginx nginx:latest

これだけだった。

• d - バックグラウンド実行
  • name - コンテナの名前指定
• p ポート指定 8000は外部からのアクセス時のポート番号、80はポートフォワーディング設定

• pオプションだけあんまりよくわかってなかったのでちょっと調べてみた

qiita.com

この記事によると8000番(Dockerコンテナ)へのリクエストをコンテナ内部の80番(nginx)に転送する感じかな？

ためしに

docker container run -d -p 9000:81 --name test_nginx2 nginx:latest

してみたけどnginxの初期表示のページが出てこなかった。
nginxのポートはデフォルトが80番みたいなので上記の解説であってるはず

タイトルは達成したけどさすがに短すぎるので停止と再起動を試す

docker container stop test_nginx

このコマンドでコンテナが停止する

docker container start test_nginx

これで起動

一回docker runすると

docker container start -p 9000:80 test_nginx

みたいにあとからオプションを変更することができないので開発中なんかは

docker container run -d --rm -p 8000:80 --name test_nginx nginx:latest

のように--rmオプションをつけて
コンテナを停止するごとに自動的に削除されるようにするのが一般的らしい

ちなみに今回は全部「docker container run」みたいにcontainerをつけたけど
「container」は省略できるから

docker run -d --rm -p 8000:80 --name test_nginx nginx:latest

とかでも同じことができる

目標も達成したし今日はここまで

Django でpython3 mange.py startapp ~~~ がエラーになった

前から予定していた掲示板アプリを実際に作り始めたところすぐに詰まったので特にハマったわけでもないけど記録

 django-admin startproject boardproject

からの

python3 manage.py startapp board

で以下のエラー

Traceback (most recent call last):
File "manage.py", line 21, in <module>
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "/home/carametal/.local/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
utility.execute()
File "/home/carametal/.local/lib/python3.6/site-packages/django/core/management/__init__.py", line 357, in execute
django.setup()
File "/home/carametal/.local/lib/python3.6/site-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/carametal/.local/lib/python3.6/site-packages/django/apps/registry.py", line 91, in populate
app_config = AppConfig.create(entry)
File "/home/carametal/.local/lib/python3.6/site-packages/django/apps/config.py", line 90, in create
module = import_module(entry)
File "/usr/lib/python3.6/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'board

どうやら python3 manage.py startapp board する前にINSTALLED_APPSに 'board'を追加してしまったこと原因らしい。

内部的にどんな処理か見てないけどsettings.INSTALLED_APPS内にすでに新規に作ろうとしているアプリ名があると
同じエラーが出るみたい。

INSTALLED_APPSに追加するのはstartapp後、簡単なことなのでしっかり覚えていきたい。

「小さなチーム、大きな仕事」を読んでみた

前回に引き続き組織論系の本を読んだので感想を書いていく。

今回は２冊目「小さなチーム、大きな仕事」について

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

全体的な感想

もっとチームを運用する上での知識やTIPSが載っている本かと思ったけどそうではなくて、心構えや意識的な内容が多かった。初めて見るような内容はほとんどなかったが、バイブル的にたびたび読み返してみると目の前の問題を解決する糸口をつかめるかもしれない。そんな印象を受けた。前回読んだ「エンジニアリング組織論への招待」とは違った理解できないよな内容はまったくなく、スラスラと読むことができた。しかし、難しくなくシンプルだからこそ強力な効果が得られるんじゃないだろうか。これは依然読んだ「SIMPLE RULES」で書かれていた基本的で簡潔な美しいルールの先にこそ素晴らしい成果が待っている。という考えに通づるものがある気がする。

SIMPLE RULES 「仕事が速い人」はここまでシンプルに考える (単行本)

 「小さなチーム、大きな仕事」は厳格なルールに関する本ではないけど、自分、もしくはチームの判断基準、行動指針として徹底していくべき本だと思った。

印象的だった内容 

顧客を（あなたよりも）成長させよう

 心惹かれた内容はいくつもあったが特別刺さってきたのがこれ。

僕は現在、SESによる客先常駐で仕事をしていてあまりチームとして知見が溜まってどんどん成長する組織の中にいるわけではない。なので常駐先によってはコードは汚いしパフォーマンスもよくない、技術的に成長しようという意思が感じられないようなメンバーも少なくない。そんな状況からもっと技術的に優れたプロジェクトへ移りたい、自社開発の企業へ移ってその中で成長したいと感じることが多かった。今でも自社開発をしたいという思いは変わらないが、チームへの不満をもったままにするよりもそのチームを成長に導くという考えをするべきだった。

たしかに今後のことを考えると自社開発、特に自社製品を持つ企業で経験を積みたいがそれはあくまで今後の方針で会って今すぐにできることではない。結局、今できることをするしかない。そう考えたときに今できるベストのことは客先のチームを成長させることしかないと思う。じゃあチームにどう影響を与えられるかと考えたときに、チームメンバーと比較して僕が優れているのはきれいなコードを書くことや、若い世代の考えを伝えることという結論に至った。きっとチームを成長に導くことができれば、自分にとっても大きな成長、大きな経験になるのだと思う。

無名であることを受け入れる

 今まさに僕がそうなのだが、無名であることは多大なメリットがあると教えてくれた章。有名になる、つまり規模が大きくなり人気がでてくるとリスクが小さい行動をとらざる負えなくなり、保守的にならざる負えない。無名であるというのは成功者であるというプライドを失うこともない。そんなときにこそ他人にあれこれ指摘されずに失敗を繰り返して成長をすることができる。次々と新しい挑戦を繰り返すことこを今すべきこと。自分のことを考えるとやはり失敗したときのリスクが怖くて挑戦ができなくなってしまうが、無名で何も持たない今だからこそ挑戦のリスクは少ない。どんどん挑戦して失敗を重ねていこうと思う。本書では失敗から学ぶことは過大評価されすぎている。という章もあるが、失敗ばかりで成功しない状況と、成功の中に失敗があるのではまるで状況が違う。成功することも大事だが、成功しかないという状況は新たな挑戦ができていないということでもある。無名の今だからこそリスクを負った挑戦ができる。心にとめて日々挑戦していきたい。

まずは作り始めよう

 この章に書かれていることはアイディアなんて持っていても意味がない。なんでもいいから作り始めろということ。僕は将来、自社開発を行う企業で自社製品開発をしたいと思っている。自社製品開発で活躍するには技術力だけでなく、製品を成長させるための知見やアイディアが必要になる。その経験を積むためにまず技術力を身に着けて自社製品を持つ企業に転職する必要があると思っていた、実はそうではない。まず、自分で何かを作ることが何よりも大事で、自分で作ったことがあるという経験が自社製品開発のための大きな経験になるし、技術力の成長にもつながる。そしていざ自分で何かを作るとなったときに、何を作ればよいのかと思ってしまうこともある。この章に例として書かれている通り、一番大事なのは始めることでまずはなんでもいいから作る。作りながらより良い作るべきモノや、作り方を学んでいけばいい。僕自身技術を身に着けようと技術書を読んだり、チュートリアルをやってみたり、Qiitaや技術ブログのTIPSを漁ったりを繰り返してきたが、今やるべきことはオリジナルの製品を作り出すことで、作りながら成長していくこと。なのでこのブログが書き終わったらさっそくブログアプリでも作ろうと思う。前にUdemyで作った掲示板アプリにリプライ機能を追加してみるのもいいかもしれない。

まとめ

 振り返ってみると印象に残ったことは「まずやれ」ばかりで、いかに自分が行動不足か思い知らされる。正直、読む前に期待していた内容とは全然違ったが成果を出すための内容が詰まっていて本当に読んでよかった。今はチームをまとめる立場ではないので僕個人が成長していくためという視点で読んでしまったが、もっとチームの中心を担うようになったときにはまた違った見方ができると思う。前回読んだ「エンジニアリング組織論への招待」も含めて、チーム・組織運用で悩んでいるリーダーやマネージャー、経営者は読んでおいて損はないと思う。また僕のようにいまいちなチームに物申したい。いつかチームをまとめる側になったときのために組織論を学んでおきたいという人には心からおすすめできる書籍でした。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

「エンジニアリング組織論への招待」を読んでみた

今年の７月から現場でスクラム開発が取り入れられたもののなかなか成果が発揮できずモヤモヤとしていたのでチーム設計や運用書籍を購入してみた。

購入したのは以下の２冊

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

小さなチーム、大きな仕事――働き方の新スタンダード (ハヤカワ・ノンフィクション文庫)

 今回は１冊目「エンジニアリング組織論への招待」について書いていく。

全体的な感想

 正直全部は理解できていない。初めて聞く概念が多くもっと深く読み込まないと感覚的に落とし込めるとこまで行けそうにない。でも、現場のチームにおいてモヤモヤとしていた部分の霧が晴れていくような感覚が随所にあった。特にChapter3「アジャイルなチームの原理」とChapter4「学習するチームと不確実性マネジメント」はまさに今求めていた情報が詰め込まれていてどんどん読み進んでいった。先行してスクラムを取り入れていたチームと情報交換をしたときに出ていた「心理的安全性」というワードなんかも出てきて、そういえばソニックガーデンさんのブログで見たことあるなぁとか思い出すこともたくさんあった。

印象的だった内容

 心理的安全性

まずは、上記にも上げた心理的安全性について

現場では心理的安全性については、見積もりを納期だと思ってしまっていることでプレッシャーが生まれ、開発効率や品質の低下が発生してしまう。という点でしか今までは語られていなかったが、「対人リスク」という概念についてはなるほど。と思った。対人リスクとは「相手の問題を指摘」したり「自分の失敗を報告」したりする際に発生するもので、自分の評価が下がってしまうのではない、相手に悪く思われてしまうのではないかというリスクのこと。僕自身あたり他人にどう思われるかを気にして発言するタイプではないが、相手の気分を害してしまわないか、場の雰囲気を壊してしまわないかという部分に関しては気おくれしてしまうことがある。心理的安全性が高いことでそのような状況でも積極的に発言ができるようになるというのは最大のメリットのように思う。

それを踏まえて考え直してみると、心理的安全性には納期に対する不安というものも含まれているが、「対人リスク」と比べるとさほど重要ではない気がする。むしろ、土台というか、チームを運営する上でできていなければならない非常に基本的なことのような気がしてきた。

YOUメッセージとＩメッセージ

これは組織論というよりも対人関係やコミュニケーションの取り方についてで、たまにネットやテレビでも目にしていたが改めて読んでいたかなり有効な技術だなと思った。

本書では遅刻を例に挙げている。遅刻した人に対して「なんで（あなたは）遅れたの？」と発言をしてしまうとそのような意思はなくても責めているような印象を与えてしまうが、「連絡がないから（私が）心配したよ」というと伝えることで責められるような印象を減らすことができるうえ、相手を「承認」しているというメッセージを伝えることができるらしい。「承認」に関してはまだ感覚的な理解ができていないが、人間関係には非常に重要な要素だと思うのでＩメッセージを日常から意識して発言することは大きなメリットだと思う。

現場での失敗に対してリーダーがメンバーに対して「なんで失敗したと思う？」という発言をしていて、もっと良い言い方はないのだろうかと思っていたがこれはYOUメッセージに該当するためで責めている印象になっていたことによる不満だったのだと思う。ただこのケースでは原因を追究し対策するという目的を考えるとＩメッセージに置き換えるのは少し難しいかなとも感じる。この場合は「（私は）あなたにならできたと思う。」もしくは「たしかに今回は難しかったと（私は）思う」と伝えたうえで「なんで失敗したのか」ではなく「何が原因だったのか」を聞くのが良いのかな。

あくまで見積もりは予測

「見積もりは予測であって、ノルマではない」という言葉が本書に出てきたときには、ハッとさせられた。見積もりはあくまで見積もりであって納期ではないと考えてはいたが、やはり心のどこかで見積もり内に終わらせなくてはいけない、という思いがあったように思う。さらに見積もりをノルマととらえてしまうことで、ノルマをクリアするための見積もりをする→余分なバッファをとる→開発スピードが低下するという負のサイクが発生してしまう。ということは考えたことがなかった。一般的に顧客は見積もりを超えてしまうと不満を持ってしまうと思うが、「見積もり通りに開発がすすむこと」と「開発スピードが速いこと」のどちらが良いか考えたときにどう考えても「開発スピードが速いこと」のはずなので、顧客にとっても見積もりはノルマになってしまうことはデメリットになるはず。お互いに見積もりはあくまでも予測であって、ノルマではない。ノルマと考えてしまうことでデメリットが発生するという情報を共有することで見積もりのズレも納得してもらえるかと思う。

 日本人はアジャイル開発が苦手

 今までネット上でも日本人の性格上、アジャイルになじみにくいという話をたびたびめにしていたが、そのたびにそんなことはないだろうと不満に感じていた。僕のチームでスクラムを取り入れる際にも、先行してスクラムを取り入れていたチームのリーダーが「日本人にはアジャイルは難易度が高い」といった発言をしていて気に入らないな、ともってしまったが、本書によると「権力格差許容傾向」、「成果主義傾向」、「不確実性回避傾向」といったスコア(ホフステード指数)を国際的に比較しアジャイル導入の難易度を調査するという研究が行われており、日本がもっともアジャイル導入の難しい国であるという結果が出たようだ。研究対象国が何か国なのかは不明だが(ソースにたどり着けなかった)もっとも難易度が高い、ということは現在の日本文化にはよっぽど合っていないのだろう。そう考えるとたしかに導入は難しいかもしれないがアジャイルを導入する企業が増えていくことで今後国民性の変化も期待できるかもしれないなと思った。

まとめ

 このほかにもかなり多くの気になる内容や、深く読み込みたい部分もあったが、特に印象に残ったのは以上の４項目だった。これ以外には対人におけるコミュニケーションについて心理学的に語られている部分があったり、チーム・企業運用におけるコストやスケジュールの管理の方法論について非常にためになりそうな内容が数多く書かれていたので、またタイミングを見て読み直したい本だった。アジャイルの歴史的背景なんかも書かれているのでチームが行き詰ったときのヒントになるかもしれないと思う。

今回はスクラム導入で行き詰ったためのヒントを求めて購入したが、本当に買ってよかったと思う。もう一冊「小さなチーム、大きな仕事」についても読み終えたら来週あたりにブログを投稿したい。

djangoのCreateViewによるデータの作成ができなかった話

Udemyのセールで買った講座を進めていたらCreateViewを使ったデータの作成でハマったため、今後の備忘録として投稿。 

formタグの「enctype="multipart/form-data"」のenctypeの綴りが間違っていたことが原因の模様。

詳細はこちらの投稿(http://mugenup-tech.hatenadiary.com/entry/2014/08/28/100910)を参照

こちらの投稿は「Webを支える技術」を参考にしたようです。僕も過去に読んだはずなんですが内容をほとんど覚えていないのでWeb系の仕事をやっているこそ読み直してしっかりと頭に叩き込む必要を感じた一日でした。