Twilioハンズオン（初期設定）
Ansibleでシェルを実行させる時の注意点
概要
Ansibleで以下のようにshellモジュール（shell:）で、シェルを実行させようとした時、（シェルは正常終了しているが）シェル内のaws cliコマンドが実行されていない！とハマったのでメモ。
shell: /home/hoge/scripts/test.sh {{ hoge_name }} && sleep 2s
原因
・Ansibleで対象サーバ内のシェルを実行させる際にデフォルトで使われるのはbashではなかった
shellモジュール実行時のシェルは「/bin/sh」であり、ログインシェルは実行していない（.bash_profile等を読み込まない）
・aws cliコマンドを実行する際にパスが通っていないことが原因だった
対処法
・環境変数を設定し、aws cliのパスを通してあげる。 以下のように「environment」を指定してあげるとこの処理の時だけ指定したパスで実行してくれるので便利
- name: LB_OUT; /home/hoge/scripts/test.sh
shell: /home/hoge/scripts/test.sh {{ hoge_name }} && sleep 2s
environment:
PATH: /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
当たり前のように/bin/bashで実行されるものだと思い込んでいたので、こういう罠にハマりました。 今後も忘れないようにしなければ。
LBのリスナーでBL/GRのターゲットを切り替えるシェル
概要
BL/GR切り替えをLBのリスナーからターゲットグループで切り替えることを実装する際に使用したシェルをメモ的に記載します。
【動作前提】
・BL/GRのEC2が共に起動中であること
【動作要領】
・ALBのリスナールールにて向き先のターゲットグループを切り替えることによりBL/GRのEC2を切り替える
・シェル実行時にリスナーのデフォルトの向き先がBLであればGRに切り替え、GRであればBLに切り替える
シェルスクリプト
以下の内容のシェルスクリプトを作成し、必要な場所に配置して実行する。
#!/bin/bash ## MESSAGE FUNCTION function alert () { echo "$(date '+%Y-%m-%d %H:%M:%S') [$1] $2" } ## VARIABLES PRD_ALB_ARN="ALBのARN" PRD_BL_PC_TG_ARN="Blue用のPCのTGのARN" PRD_BL_SMT_TG_ARN="Blue用のSMTのTGのARN" PRD_GR_PC_TG_ARN="Green用のPCのTGのARN" PRD_GR_SMT_TG_ARN="Green用のSMTのTGのARN" PRD_LISTENER_ARN="ALBのリスナーのARN" ## CURRENT COLOR PRD_CURRENT_COLOR=$(aws elbv2 describe-listeners \ --listener-arns ${PRD_LISTENER_ARN} \ --query 'Listeners[].DefaultActions[].TargetGroupArn' --output text | cut -d/ -f2 \ ) ## CHANGE TARGET TO ANOTHER COLOR if [ "${PRD_CURRENT_COLOR}" = "bl-pc-http-tg" ]; then aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_GR_PC_TG_ARN} \ --conditions Field=path-pattern,Values='/sitemap/*' \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_GR_PC_TG_ARN} \ --conditions Field=path-pattern,Values='/assets/custom_sitemap*' \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_GR_PC_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_GR_SMT_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_GR_SMT_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-listener \ --listener-arn ${PRD_LISTENER_ARN} \ --protocol HTTPS --port 443 \ --ssl-policy ELBSecurityPolicy-2016-08 \ --default-actions Type=forward,TargetGroupArn=${PRD_GR_PC_TG_ARN} alert "SUCCESS" "ALB LISTENER CHANGE TARGET GREEN" exit 0 elif [ "${PRD_CURRENT_COLOR}" = "gr-pc-http-tg" ]; then aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_BL_PC_TG_ARN} \ --conditions Field=path-pattern,Values='/sitemap/*' \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_BL_PC_TG_ARN} \ --conditions Field=path-pattern,Values='/assets/custom_sitemap*' \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_BL_PC_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_BL_SMT_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-rule \ --actions Type=forward,TargetGroupArn=${PRD_BL_SMT_TG_ARN} \ --rule-arn ${PRD_ALB_ARN}:<ルールのARN> aws elbv2 modify-listener \ --listener-arn ${PRD_LISTENER_ARN} \ --protocol HTTPS --port 443 \ --ssl-policy ELBSecurityPolicy-2016-08 \ --default-actions Type=forward,TargetGroupArn=${PRD_BL_PC_TG_ARN} alert "SUCCESS" "ALB LISTENER CHANGE TARGET BLUE" exit 0 else alert "ALERT" "ALB LISTENER HAS NO COLOR" exit -1 fi
あやうく一生懸命生きるところだった
韓国人のハ・ワンさんが、人の生き方について書いた本のレビューです。
私はこの本を読んで、衝撃を受けました。
もっと早く出会いたかったですが、今出会っておいて良かったとも思います。
人生はみんな努力でコントロールできると思っているのがまず間違えだということ。
人生とは答えのないなぞなぞを解くようなものだと表現されていて、良い意味で力が抜けて、気持ちが軽くなりました。
結局、うまく生きる答えなんてないのに、答えがあると思い込み、それを得るために執着してしまう。
自分の人生を振り返ってみると、やっぱりものすごく執着してたなぁと思います。
高校時代は有名な大学に行けば将来安泰で良い会社に就職できると思っていました。
大学時代の就活では、私の時は2010年卒で金融危機が起こった就職氷河期の一発目だったので、就職自体も難しく、こういう状況下でも新卒を雇えるような「大企業」が大人気でした。
何が起こっても大企業であれば大丈夫。。そんな雰囲気がありました。
ですが、そこから10数年たち、今コロナの時代に入り、「大企業なら大丈夫」という誰も疑わなかったことが大丈夫ではなくなりました。
女性の働き方で言えば、女性の社会進出が叫ばれていた時ではありましたが、「新卒で大手企業に入社して、結婚して退職する」という選択肢を考えていた人も多かったと思います。
女性だからそこまであくせく働く必要はないと。
ただ、2020年現在思うのは、コロナになり失業や減給が増える中、大変ではあるけれども自分が働き続けることを選んだ女性は、割と安心して生活できているのではないかと思います。
そして、ジェネラリストよりスペシャリスト（専門職）を選んだ人の方が、1人で仕事を完結できる分、融通がききやすいのかなとも思います。
求人を見ても、コストセンターと認識される職業の求人は見かけなくなりました。
人生何が起こるかわからないから、結局人生をコントロールするなんてできないし、素敵な将来を得られると信じられていた選択肢まで、今となっては本当に魅力的だったのか疑問です。
この本を読んで、やる気を無くした訳ではなく、逆に肩の荷が下りて気楽にやる気になれました。
みんな不安定なものにやたら執着するように世の中に仕向けられているだけなんだと。
想い描いていたもの素敵な未来像は、幻想でしかなかったのだと。
だから、自分の物差しで自分の好きなように生きれば良いのだと教えてもらえた気がしました。
こういう本に出会えれば、きっと自殺する人も少なくなると思います。
やはり、良い本は偉大です。
コロナ時代の遊び方を考える
今回はエンジニア系の話ではなく、コロナになって人と会わなくなった、出かけにくくなった時代の楽しみ方を自分なりに考えた結果を書こうと思います。
コロナになって、仕事は完全在宅勤務になりました。
通勤していた時は社員の顔が見れていたし、特に仕事で話を積極的にしなかったとしても何となく人が視界に入って一生懸命仕事している姿を見るだけで、自ずと自分のやる気が出たり、良い影響をもたらしていたことに気づきました。
なくなってみると、その環境がいかに大事だったかがわかるような気がします。
そして、友人と話していて思うのは、人とリアルなコミュニケーションができなくなり、1人で生活することになったことによりストレスが溜まっているということ。
人間観察が趣味でもそれももうできない、外に出てもマスクをしている人を眺めるのは面白くない、外で遊びたくてもレジャー施設はしまっているとか開いていても行きにくくなっている。。この状況だと人生がつまらないと。
減給されたりボーナスカットされたり、転職もままならなくなってしまった等々で不安だという友人もいました。
今、大事なことは何なのか、ということですが、まずは状況を把握して、その状況にあった自分を幸せにする術を見つけることだと思います。
状況という点で、コロナになって、気軽に外に出てレジャーを楽しむことができなくなったということ。
まずはそういう時代なのだから、外で遊ぶのは諦めると決めてしまうことだと思います。
ただただ外遊びができないと嘆いていてもしょうがないし、負の感情しか生まないので、みんな同じ状況だし、じゃぁ家でできることを楽しもうと割り切ることが大事だと思います。
コロナは季節性のものではないし、いつおさまるかなんていうのを期待するのも意味がないと思うので、せっかくだから家での遊びを創造しようと気持ちを切り替えるのが良いと思います。
家で1人で遊べる力というのが、コロナで求められる力になっていると感じますが、これは1人の人間として精神的に自立できているかが同時に試されているような気がします。
人と接する上で、誰もがこの精神的自立がある人と関わりたいでしょう。
1人でいると寂しくて何もできないとか、愚痴ばかり言って誰かにかまってもらうとか、正直なところ、迷惑です。
相手に幸せにしてもらうことばかり考えているのではなく、自分で自分を幸せにできる力がないと、相手に悪影響を及ぼします。
結婚生活もそうです。
かまってちゃんで旦那の仕事を邪魔するとか、早く帰ってこないと愚痴をこぼすとか、本当によくないことだと思います。
自分で自分を幸せにできる人であればそんなことはしないはずです。
むしろ相手の幸せを願って、与えることを考えると思います。
そうすると旦那も、仕事が忙しく構ってあげられなくても、1人で楽しんでくれるし、自分のことを思って何かしてくれると感謝します。
独身のカップルでも、こういう1人で楽しめる人であれば結婚できるだろうと、結婚する時の基準にするのだと思います。
女性の社会進出が求められている時代ではありますが、実際のところ、そこに対して環境を整えてくれる会社は多くないと思うので、女性もずっと働き続けるべきとか、高い稼ぎが必要とかは思いません。
経済的自立に関しては必須事項ではないと感じますが、精神的自立は必須事項です。
コロナは人々に精神的自立という試練を与えにきたのかとさえ思います。
前置きが長くなりましたが、必要なことは、以下をまとめることだと思います。
①自分が何が幸せかを知る ②自分の幸せのハードルを下げる ③自分が家で楽しめる方法を考える
①に関しては、自分の好きなことや好きなものを50個書き出すのが良いと思います。
50個もあると途中でもうないかなと考えがちですが、今ではなくても過去の自分、昔好きだったこと等を思い返してみると挙げられたりします。
別にものすごく好きなことじゃなくても続けて苦にならないことは好きなことに分類すると挙げやすいです。
そしてジャンル問わず50個好きなことが見える化されると自分を自分で客観視することができるようになります。
②に関しては、毎日の気づかない幸せを幸せだと認識することだと思います。
例えば、美味しいご飯が食べた、その瞬間に「幸せだなぁー」と思うこと。それをやり続けると脳にインプットされてくるので幸福感が増します。
文字に起こしてみるのも良いと思います。
③に関しては人それぞれ違いますが、①でリストアップされた内容を見ながら、家で1人でできることをピックアップするのがオススメです。
①と③は必ず書き出してみてください。
きっと何かしら発見があるはずです。
ここからは自分の備忘録として。
私の場合は、以下のようにテーマをおきました。
③のテーマ：「家で1人でできることでお金を極力かけないで実施できるもの」
お金を極力かけないという部分が達成できた場合、自分で自分を褒めてあげることにしました。
もちろんこういう節約行為は自分でやること限定としています。
テーマにのっとって自分の好きなものから、削減するものと取り入れるもの（引き続き取り入れる/より取り入れる）に分けました。
＜＜ 削減するもの ＞＞
・外食
- ランチ中心、夜の外食は極力避ける。
- 頻度はランチは週1まで、ディナーは月2まで。（あくまで目安なので臨機応変に）
・旅行
- 行かない。国内でも遠出はせず、関東圏まで。
・服 / コスメ
- 基本、デパートや商業施設に行かない。 必要なものしか買わない。（正直、興味もなくなってきたというのもある。）
- 洋服はメルカリ等を活用する。
・美容院
- 行かない。自分で髪も染める。リタッチもやる。（実際に自分でリタッチしたらうまくできたので、今後も継続決定。）
・整体 / マッサージ
- 痛みが取れたら通わない。（実際に継続を勧められましたが、痛みが取れた時点でやめました。ゴールも見えないし。）
・音楽
- 大好きなのですが、イヤーワーム状態になり何かに集中する時邪魔なので聴かない。（個人的なところですが勉強に集中できなくなる。。）
＜＜ 取り入れるもの ＞＞
・アマゾンプライムビデオの活用
- （他の動画配信サービスも使ってましたが）アマゾンプライムビデオのみにすることに決定。（一本化し、もっと活用しようと思った。）
・テレビ
- 面白い番組を積極的に観る（あまり見ない方だったけど、おもしろコンテンツやタメになる番組が多いのでそういうのは積極的に見る。）
- ニュースを観る
・本
- 興味ある本をできるだけ中古で購入し読む（個人的には活字を読まないとボキャブラリーが減ってくる気がするのでこれが一番取り入れたいこと。）
・料理
- レジャーとして作るのを楽しむ（美味しくできたら自分で褒めてあげるのが良い。）
- いろんな創作料理にチャレンジ（発想力も磨けるし、気分転換にもなるし、料理上手くなる。）
- 健康を意識した料理を検討（美味しくてもカロリー高いと太って気分悪くなりそうなのでここも意識。野菜を多く取り入れるような料理が良い。）
- 食材はあるものを使うと決める（無駄にスーパーに行きまくってると意外に出費するし面倒なので、気楽にあるものでやる。）
・ランニング
- 筋肉痛が激しくない限りできるだけ毎日やる（家ではできないが、夜や人が少ないタイミングで。）
・ストレッチ
- お風呂上がりに軽くやる程度。これは毎日続ける。
・zoom等のオンライン会話
- 友人とのおしゃべりに活用（1時間くらいでお互いにラフにできると良い。）
・ネットサーフィン
- 技術のキャッチアップ （自分的にはここもっと重要視したい）
- 興味のあるネット記事を読む（目に入ったものを気軽に）
- 動画コンテンツ（ITの勉強系のものや、Youtube等も）
あとは、家ではできないがたまにであればレジャーとして映画を観に行ったりもありだと思います。
猫カフェやカワウソカフェ等動物に触れ合えるところも良い。
こんな感じで整理されると、とっても気分が良いし、漠然とした将来への不安感もなくなってきます。
コロナ時代の一人遊びを楽しめますように。
Docker基礎 - 必要なことだけメモ①
Docker Engineの構成
・Docker Engineは一般的なクライアント／サーバーシステムとして動作する
・コンテナーの管理をDockerサーバーが、サーバーの操作をDockerクライアントが担う
・Dockerクライアント、サーバーの状態はdocker versionコマンドでバージョンと共に確認できる
$ sudo docker version
Dockerのコンテナー管理のライフサイクル
・Dockerコンテナーは、元となるDockerイメージというテンプレートから作成する
・Dockerコンテナーは実行中と停止の状態があり、コンテナーで実行するプロセスの状態と連動する
・Dockerコンテナーの管理はコンテナーの実行／停止と新たなイメージ作成の繰り返し
・Dockerコンテナーの変更とDockerイメージの作成は、Dockerfileというテキストファイルに変更内容を記述して「docker build」コマンドでバッチ的に行うことが可能
Dockerイメージをダウンロードする「docker pull」コマンド
・Dockerイメージは、コンテナーを実行するために必要な全てのディレクトリ／ファイルを含むアーカイブと、コンテナーのメタ情報を持つ
・多くのベースイメージはDocker Hub Registryで公開されていますので、そこからダウンロードするのが一般的
・DockerレジストリからのDockerイメージのダウンロードは、docker pullコマンドを実行する
-- どのイメージにするかは、引数で｛イメージ名｝（Repository）と｛タグ名｝（Tag）で選択
-- ｛タグ名｝はGitなどと同様、Dockerイメージのバージョンを示す
$ docker pull ｛イメージ名｝:｛タグ名｝
・初期設定では、Dockerレジストリとして「Docker Hub Registry」にアクセスするようになっており、Docker Hub Registryで公開されている多くのベースイメージには、最新版（latest）のタグが設定されている
・｛イメージ名｝はDocker Hub Registryで好みのイメージを検索し、｛タグ名｝は特別な要件がなければ、latestを指定する
・ダウンロードしたDockerイメージは、レジストリのイメージと区別するために「ローカルキャッシュ」と呼ぶこともある。このローカルキャッシュからDockerコンテナーを実行する。
ダウンロードしたDockerイメージの一覧を確認する「docker images」コマンド
・ダウンロードしたDockerイメージ（ローカルキャッシュ）の一覧は、docker imagesコマンドで確認する
$ docker images
Dockerコンテナーを作成・実行する「docker run」コマンド
・DockerイメージからDockerコンテナーを作成、実行してみる。docker runコマンドで、コンテナーの新規作成と実行の両方を行う。
$ docker run [オプション] [--name ｛コンテナー名｝] ｛イメージ名｝[:｛タグ名｝] [コンテナーで実行するコマンド] [引数]
・タグ名は省略可能。--nameオプションおよびコンテナー名を省略すると、英単語を組み合わせたランダムなコンテナー名がDockerコンテナーに設定される。
▼ 主なオプション
-d：バックグラウンドで実行する（後述）。既定では、コンテナーをフォアグラウンドで実行するため、Webサーバーやアプリケーションサーバーなど常時実行するコンテナーで指定
-i：コンテナーの標準入力を開く。/bin/bashなどでコンテナーを操作する際に指定
-t：tty（端末デバイス）を確保する。/bin/bashなどでコンテナーを操作する際に指定
-p ｛ホストのポート番号｝:｛コンテナーのポート番号｝：Dockerサーバーのホストとポートマッピングを構成
▼お試し作業
ubuntuイメージからubuntu1コンテナーを作成、端末を開きbashを実行し、nginx」をコンテナーにインストール
$ docker run -it --name ubuntu1 ubuntu /bin/bash root@f66e8ee71dab:/# root@f66e8ee71dab:/# apt-get install -y nginx :(略) root@f66e8ee71dab:/# dpkg -l nginx Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=================================-=====================-=====================-======================================================================= ii nginx 1.4.6-1ubuntu3 all small, powerful, scalable web/proxy server root@f66e8ee71dab:/#
・一通り操作したら、［Ctrl］＋［d］キーでbashプロセスを終了する。プロセスの終了とコンテナーの停止は連動するので、コンテナも停止状態になる。
Dockerコンテナーの一覧を取得する「docker ps」コマンド
・Dockerコンテナーの一覧は、docker psで確認する
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f66e8ee71dab ubuntu:latest /bin/bash 37 minutes ago Exit 0 ubuntu1
-- docker psコマンドでは実行中のコンテナーのみ表示されますが、「-a」オプションを付加すると、停止中のコンテナーも表示される。
-- コンテナーの状態はSTATUS列で判断でき、「Up ｛実行時間｝」の場合は実行中、Exit 「｛終了コード｝」の場合は停止となる。
Dockerイメージを作成する「docker commit」コマンド
・Dockerコンテナーから新しいDockerイメージを作成するために、docker commitを実行
$ docker commit ｛コンテナー名｝|｛コンテナーID｝ [｛ユーザー名｝/]｛イメージ名｝
-- ubuntu1コンテナーではnginxをインストールしたので、任意の｛ユーザー名｝（test）と｛イメージ名｝（nginx）としてイメージを作成してみる
$ docker commit ubuntu1 test/nginx 7fed60d6cc60de39ea80d8fba729e9abbb9899af6bf5c7ebb0a4627aacd36ed4 $
Dockerコンテナーを停止する「docker stop」コマンド
・バックグラウンドで実行中のDockerコンテナーは、docker stopで停止する
$ docker stop ｛コンテナー名｝|｛コンテナーID｝
Dockerコンテナーを削除する「docker rm」コマンド、イメージを削除する「docker rmi」コマンド
使い終わったDockerコンテナーはdocker rm、Dockerイメージはdocker rmiで削除する
$ docker rm ｛コンテナー名｝|｛コンテナーID｝ $ docker rmi ｛イメージ名｝|｛イメージID｝
Dockerコンテナーを再実行する「docker start」コマンド
・停止しているコンテナーは、docker startで再実行する
$ docker start [-i] ｛コンテナー名｝|｛コンテナーID｝
エンジニアの仕事について思うこと
素敵な記事と出会えました。私自身も普段から思っていることを言語化してくれた記事。
これに出会えただけでも救われる部分は大きいと思うので、もしこのブログを閲覧される方がいらっしゃれば以下の記事も読んでもらえればと思います。
simplearchitect.hatenablog.com
今働いている会社でもそうですが、常に完璧を求められ、試行錯誤する環境は与えられずに一発で何とかするのが当たり前みたいな風潮があります。
期限までにリリースできたとしても、その中での失敗や少しのミスが発生するものならマイナス評価になります。
失敗やミスなく完璧にできて初めて「1」（ただし「当たり前」という評価）となり、失敗やミスが発生した場合は、全体評価が「0.5~0.8」くらいに落ちます。。
挙げ句の果てに業務に支障のないどうでも良いミスでさえ、報告書を書いて謝らなければいけなく、エンジニアとしてのモチベーションはだだ下がり。
周りのエンジニアは、感情を無にして、思考停止させて仕事をしています。そうすることが心の安定だと。
もはや失敗しないことが「最重要」になり、新しいことなんてやらないし、提案さえもしなくなる。お客さんのシステムをより良くしていこうという意識さえなくなる。目には見えないけれども、実際エンジニアの心の中では、そんなことが起こっていると思います。
成功した時に賞賛する文化がなく、失敗した時だけやたらコメントされる。実際のところ、チャレンジすることを「Good Job」と言ってくれたり、無事リリースした時に「よくやったね！」とか「お疲れ様！」とか言ってくれる人さえいません。
1人で仕事をしていると、無事リリースして、それを報告しても、みんなノーコメント。。お客さんからもグループのメンバーからも何のコメントもありません。
そうすると自分で自分に「お疲れ様！よくやった！」と心の中で励ますのですが、実際、とっても虚しい。。
虚しいけれども、エンジニアの仕事というのはそういうものなのだと思ってきました。
でも海外では違って、何か役に立つことをした際には、賞賛のコメントをきちんと投げかけ合っていて、やったことが評価に繋がってもきます。
目に見えない大事なことを見逃しがち（軽視しがち）なのではないのでしょうか。売り上げが安定してればそれで良いのでしょうか。
それが蔓延していくと、優秀なエンジニアはどんどんいなくなっていくと思います。
エンジニアがモチベーションをもって仕事をしやすい組織や文化、そして評価制度を作っていきたい。
これからは、日頃から思っていることが多かったので、組織マネジメントができる環境に身を置いて、より良い環境を作り上げていこうと思います。
