Pythonの除算(割り算)で小数点以下を切り捨てた形の整数をつくってみます。
なんだかんだしらなかったのでメモ
そのまま/で除算を行うと以下のように小数点以下も求められてしまう。
型がfloat型になってしまう。
syousuu = 5 / 2 print(syousuu) # 2.5
ただし、以下のように//で除算してあげると小数点以下を切り捨ててくれる。
seisuu = 5 // 2 print(seisuu) # 2
小数点以下を切り捨てるためにいちいちint()にいれてーとかいう必要がなくなる。
Pythonの前の心に触れます。
詳しくは以下を実行して心に刻め。
$ python Python 2.7.10 (default, Oct 6 2017, 22:29:07) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
The Zen of Python, by Tim Peters
美しいものは醜いものよりも優れています。
明示的は暗黙的より優れています。
シンプルは複合体より優れています。
複雑なものは複雑なものよりも優れています。
フラットはネストされたものよりも優れています。
疎は密なものより優れています。
可読性はいいです。
特別なケースは、ルールを破るほど特別ではありません。
実用性は純粋さを凌ぐものの。
エラーは決して黙ってはいけません。
明示的に消音しない限り。
あいまいさに直面して、推測する誘惑を拒む。
それを行うには、1つの方法が必要です。
あなたがオランダ人でなければ、その方法は最初は明らかではないかもしれません。
今は決して良いことではありません。
今は今よりよくなることは決してありません。
実装が説明するのが難しい場合、それは悪い考えです。
実装が説明しやすい場合は、良い考えかもしれません。
名前空間はすばらしいアイディアです。
いましめ
独学プログラマー Python言語の基本から仕事のやり方まで
Pythonでみなさんご存知のプレミアムフライデーを取得します。
8月の最終金曜日は31日。
31が出力されていることがわかる。
$ date Tue Aug 7 17:24:32 JST 2018 $ ./premium.py 31
なんかよくわかんないけどシャイニングマンデーなるものがあるのかないのかあるらしくそれを求めるスクリプトを書いてみた。
シャイニングマンデーは、月曜日の午前中を休みにするという制度。日本の広告代理店マンが考案した。公明党がこの制度を評価採用し2016年7月の参議院選挙の際「月曜午前半休の推進」としてマニフェストに載せ、更に2017年10月の衆議院選挙では、国会質疑等で使われていたシャイニングマンデーの名前を仮称として、この制度の普及促進をマニフェストに載せている。
月曜午前中を休みにすることにより、働き方改革として労働者の週末の疲労と週明けの憂鬱感を解消する狙いと、日曜夜の活性化や週末レジャーの幅を広げることによる経済波及効果を狙ったもの。
8月の月曜日は8/6,13,20,27なのでシャイニングマンデーが出力されていることがわかる。
$ date Tue Aug 7 17:24:52 JST 2018 $ ./shining.py [6, 13, 20, 27]
なんかオリンピックのためにサマータイムを導入するみたいな記事をみた。
普通はNTPサーバがよしなにやって、同期してくれるんだと思うんだけどなんかわからないけどそれができなかったときにdateコマンドだけでサマータイムを出してみる。
-dオプションに2 hours agoを渡すことで2時間前の時間を表示してくれる。
$ date -d "2 hours ago" Mon Aug 6 18:57:17 UTC 2018
夏
パーフェクト・サマー・ヒッツ (夏！海！ドライブ！BBQ！パーティー！完全版BEST HITS COVER)
DockerfileのVOLUME命令をつかって別のいろいろなコンテナが出力するログファイル的なものを集約してみたいと思います。
手順はこんなかんじ。
ログ格納用コンテナとログを出力するコンテナを作成してみます。
ログ用のコンテナのDockerfileはこんなかんじ。
FROM centos RUN mkdir /var/log/wawawa VOLUME /var/log/wawawa
これをbuildして
$ sudo docker build docker_file_dir/ Sending build context to Docker daemon 12.8kB Step 1/3 : FROM centos ---> 49f7960eb7e4 Step 2/3 : RUN mkdir /var/log/wawawa ---> Running in 90a3755f21cd Removing intermediate container 90a3755f21cd ---> c858715ed5a4 Step 3/3 : VOLUME /var/log/wawawa ---> Running in ea9f08e6643e Removing intermediate container ea9f08e6643e ---> 7cacfadb8df6 Successfully built 7cacfadb8df6
起動しておきます。
コンテナの中に入ったらCtrl+p→Ctrl+qで抜けます。
$ sudo docker run -it 7cacfadb8df6 /bin/bash
ログ格納用コンテナが起動しました。
$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d2241901b134 7cacfadb8df6 "/bin/bash" 7 minutes ago Up 7 minutes reverent_mayer
ログ出力用コンテナのDockerfileはこんなかんじ。
FROM centos CMD echo "ログ出力！！！" >> /var/log/wawawa/result.log
これをbuildして
$ sudo docker build docker_file_dir/ Sending build context to Docker daemon 12.8kB Step 1/2 : FROM centos ---> 49f7960eb7e4 Step 2/2 : CMD echo "ログ出力！！！" >> /var/log/wawawa/result.log ---> Running in cc0ba0db1925 Removing intermediate container cc0ba0db1925 ---> 3e2f738371a9 Successfully built 3e2f738371a9
コンテナを起動する。
その際に--volumes-fromオプションをつけることで指定したコンテナのボリュームをマウントしてコンテナを起動することができます。
あとわかりにくいですがd2241901b134がログ格納用コンテナで3e2f738371a9がログ出力用イメージです。
$ sudo docker run --volumes-from d2241901b134 3e2f738371a9
このコンテナを起動したときにCMDでecho "ログ出力！！！" >> /var/log/wawawa/result.logが実行されるはずです。
これで準備完了です。
ログ格納用コンテナの中にはいってみます。
$ sudo docker exec -it d2241901b134 /bin/bash
ログファイルをcatしてみると別のコンテナで出力したものがログ格納用コンテナに格納されていることがわかります。
# cat /var/log/wawawa/result.log ログ出力！！！
ログファイルを指定のコンテナに集約することができた。
複数のEC2インスタンスに一気にIAMロールを付ける必要があって、マネコンでポチポチするのめんどくさいなーと思ったのでつくった。
./role_fukusuu.sh IAMロール名 インスタンスID インスタンスID...
$ ./role_fukusuu.sh wawawa_role i-070c13018a4405xxx i-098ebad2dee1c5yyy
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)
DockerfileでつかえるADD命令をつかってローカルにあるtarファイルをコンテナ内に展開してみたいと思います。
こんなかんじのDockerfileを用意する。
FROM centos ADD test_archive.tar /root/
用意したアーカイブはこんなかんじ。
ADDで指定するアーカイブはDockerfileとおなじディレクトリに格納しておきます。
$ tar tvf test_archive.tar -rw-rw-r-- ec2-user/ec2-user 7 2018-08-01 13:56 wawawa.txt -rw-rw-r-- ec2-user/ec2-user 7 2018-08-01 14:21 sasasa.txt
事前準備でつくったDockerfileをもとにビルドします。
$ sudo docker build -t add_test ./docker_file_dir/ Sending build context to Docker daemon 12.8kB Step 1/2 : FROM centos ---> 49f7960eb7e4 Step 2/2 : ADD test_archive.tar /root/ ---> eb909b976b8f Successfully built eb909b976b8f Successfully tagged add_test:latest
つくったコンテナの中身を確認してみると以下のようにアーカイブが展開されて中身がコンテナに格納されていることがわかります。
$ sudo docker run eb909b976b8f ls -l /root/ total 12 -rw-rw-r-- 1 1000 1000 7 Aug 1 14:21 sasasa.txt -rw-rw-r-- 1 1000 1000 7 Aug 1 13:56 wawawa.txt
にたような機能を持つ命令としてCOPYがあります。
そっちではアーカイブの展開はできません。
tarを展開する必要があればADD
それ以外はCOPYをつかうのがベストプラクティスっぽいです。
DockerfileでCOPY命令をつかってローカルにおいてあるファイルをDockerイメージのファイルシステムのなかにコピーしてみたいと思います。
今回はローカルにwawawa.txtというテキストファイルを作成しておいて、それをDockerイメージの/root/配下に格納することを想定しています。
以下のようなDockerfileを用意。
FROM centos COPY wawawa.txt /root/
ローカルのwawawa.txtはDockerfileと同じディレクトリに格納します。
$ ls -l docker_file_dir/ 合計 8 -rw-rw-r-- 1 ec2-user ec2-user 35 8月 1 13:56 Dockerfile -rw-rw-r-- 1 ec2-user ec2-user 7 8月 1 13:56 wawawa.txt
事前準備で作ったDockerfileを指定してdocker buildする。
$ sudo docker build -t copy_test ./docker_file_dir/ Sending build context to Docker daemon 4.096kB Step 1/2 : FROM centos ---> 49f7960eb7e4 Step 2/2 : COPY wawawa.txt /root/ ---> d1443a737c8e Successfully built d1443a737c8e Successfully tagged copy_test:latest
確認のためにlsでコマンドを実行してみるとコンテナの中にwawawa.txtが入っていることがわかる。
$ sudo docker run d1443a737c8e ls -l /root/wawawa.txt -rw-rw-r-- 1 root root 7 Aug 1 13:56 /root/wawawa.txt
実際はindex.htmlとかkeepalive用のファイルとかをコンテナ上に格納するのに使うとよいのかもしれない。
またはローカルからしかとってこないファイルをこの方法でコピーするとか。
Dockerfileで記載できるONBUILD命令がいまいちよくわからなかったので実際に動かしてやってみようと思います。
以下Dockerの公式ドキュメントより(Google翻訳)
このONBUILD命令は、イメージが別のビルドのベースとして使用されるときに、後で実行されるトリガ命令をイメージに追加する。トリガは、ダウンストリームのビルドのコンテキストで実行され、あたかもFROMダウンストリームの命令の直後に挿入されたかのように実行されます。 どのビルド命令もトリガとして登録できます。
なるほどわからん
ONBUILDを記載したDockerfileでdocker buildする。
↓
イメージができる。
でもこのタイミングではONBUILDに書いた内容はイメージに適用されていない。
↓
さっきつくったイメージをもとにほかのイメージをdocker buildする。
ONBUILDの内容が反映されている！！！
つまり2回めのdocker buildで実行される処理という理解。
実際にONBUILDの動きをみてみます。
以下のようなDockerfileがあるとする。
FROM centos CMD echo "1回目だよ" ONBUILD CMD echo "ONBUILDだよ"
それをdocker buildする。
$ sudo docker build -t onbuild_test ./docker_file_dir/
こんなかんじのイメージができあがった。
$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE onbuild_test latest 73429113ed11 8 seconds ago 200MB centos latest 49f7960eb7e4 8 weeks ago 200MB
それを docker runしてみる。
$ sudo docker run 73429113ed11 1回目だよ
「1回目だよ」というメッセージが出力された。
ONBUILDの部分は無視されていることがわかる。
2回目のdocker build用に以下のようなDockerfileを用意する。
FROM onbuild_test RUN echo "2回目だよ"
そしてさきほど1回目で作成したDockerイメージをもとにdocker buildする。
$ sudo docker build -t onbuild_test_2 ./docker_file_dir/
こんなかんじのイメージができあがった。
$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE onbuild_test_2 latest 90ae6685a141 9 seconds ago 200MB onbuild_test latest 73429113ed11 10 minutes ago 200MB centos latest 49f7960eb7e4 8 weeks ago 200MB
それをdocker runしてみる。
$ sudo docker run 90ae6685a141 ONBUILDだよ
今回使ったDockerfile内に特に記載もないのに「ONBUILDだよ」というメッセージが出力された。
1回目にdocker buildしたときの情報を保持していて、それをもとにあらたなイメージをビルドしたときに処理を実行していることがわかる。
ONBUILDはベースとなるイメージをもとにさらに派生でイメージをビルドしたときに実行される。
ベースとなるイメージを管理者が作成して、そこにONBUILDで必要な処理を記載しておく。
それをもとに開発者があたらしいイメージをつくって開発を行う。みんなが好き勝手イメージをつくってもベースとなるイメージをもとにしていれば必要なものは入っているので問題ない。
みたいなことができそう。
コンテナを実行したときにDockerfile内にかかれているコマンドの引数を指定して実行させて見たいと思います。
ENTRYPOINTとCMDを利用します。
たとえば、以下のようなDockerfileがあったとします。
FROM centos ENTRYPOINT [ "echo" ] CMD [ "nanimonasi" ]
それをbuildして実行してみます。
docker runの際に以下の様に渡したいコマンドを記載してあげます。
$ sudo docker run 3309871ee2d3 wawawa wawawa
するとDockerfile内のCMDが上書きされてdocker runが実行されるので、`echo "wawawa"が実行されることになります。
当然別の引数でもOKです。
$ sudo docker run 3309871ee2d3 sasasa dadada sasasa dadada
docker runの際になにも引数を指定しないと以下のようになります。
$ sudo docker run 3309871ee2d3 nanimonasi
echo "nanimonasi"が実行されているということです。
応用がききそう
Dockerfileを書いていて、CMDとENTRYPOINTという命令があって、どっちもコマンドを実行できて、これなんやねんと思ったので雑まとめ。
単純にコマンドを実行できる。
ただし、docker run時にコマンドを指定すると処理がうわがかれる。
たとえば以下のようなDockerfileがあったとする。
FROM centos CMD echo "CMD"
それを普通にdocker runすればなんの問題もない。
echo "CMD"が実行される。
$ sudo docker run 7bb22e4b8dbe CMD
ただしdocker runのときにたとえば以下のように実行したとする。
$ sudo docker run 7bb22e4b8dbe echo "wawawa" wawawa
すると、Dockerfile内のCMDの記述が上書きされ、Dockerfile内で記載したecho "CMD"は実行されない。
なぜならCMDはDockerfile内に一つしか宣言できないから。
コマンドを実行できる。
CMDとは違い、docker run時にコマンドを指定しても処理がうわがきされない。
コンテナ実行時にかならず実行させたいものをここに記載する。
たとえば以下のようなDockerfileがあったとする。
FROM centos ENTRYPOINT echo "ENTRYPOINT"
docker runのときにたとえば以下のように実行したとする。
CMDの場合はこれで処理が上書きされてしまっていたが
$ sudo docker run f74b3addb0bf echo "wawawa" ENTRYPOINT
ENTRYPOINTは上書きされない。
ちなみにENTRYPOINTもDockerfile内に一つしか宣言できない。
複数宣言した場合は最後のENTRYPOINTが有効になる。
DockerfileでRUNとCMDという命令があって、どちらもコマンドを実行できるらしく、なんでこれふたつあるんだろうなーと思ったので雑まとめ。
docker buildのときに実行される。
なのでyum installとかapt-getとかはこの処理で記載するとよい。
docker runのときに実行される。
なのでサービスの起動などはこの処理で記載するとよい。
逆に言うとRUNでサービスの起動を記載してもコンテナ起動時にサービスが立ち上がってないみたいなかんじになる。
コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤
Dockerfileを書いていて、あーここあとで変更入りそうだしかんたんに変えられるようにしたいなー何回も書くのめんどくさいなー変数つかいたいなーと思ったので調べてみた。
Dockerfile内でARGというところで変数を定義してあげるといいらしい。
ためしに以下のようなDockerfileを用意してdocker buildしてみる。
FROM centos
ARG hennsuu="wawawa"
RUN echo ${hennsuu} > /root/result.txt
docker buildして
$ sudo docker build -t tes ./docker_file_dir/
Sending build context to Docker daemon 3.072kB
Step 1/3 : FROM centos
---> 49f7960eb7e4
Step 2/3 : ARG hennsuu="wawawa"
---> Running in 53a05c0e7800
Removing intermediate container 53a05c0e7800
---> 5426a06924da
Step 3/3 : RUN echo ${hennsuu} > /root/result.txt
---> Running in 58118ee29383
Removing intermediate container 58118ee29383
---> 622d0f8f8bb0
Successfully built 622d0f8f8bb0
Successfully tagged tes:latest
docker runでなかにはいって
$ sudo docker run -it 622d0f8f8bb0 /bin/bash
確認してみると変数が無事に認識されていた。
# cat /root/result.txt wawawa
このARGに定義した変数はdocker buildのタイミングでしか使われない。
# echo ${hennsuu}
↑echoしてもなにもない意
べんり
docker buildするときに利用するDockerfileはそのままファイル名でDockerfileとなっていないと読み込まれませんが、これだとファイル名で管理ができません。
docker buildするときにオプションとして-fをわたしてあげると任意の名前のDockerfileを読み込ませることができます。
概要で全部書いてしまったが以下コマンド例。
オプションで-f ファイル名 格納場所をわたせばOK
今回の場合はtekitouna_docker_fileというDockerfileをdocker_file_dirというディレクトリに格納している。
$ sudo docker build -t wawawa -f docker_file_dir/tekitouna_docker_file docker_file_dir/
ファイル名と格納場所を指定するというところがすこしめんどくさいしわかりにくいが、任意の名前のDockerfileでdocker buildすることができた。
