概要
VPCを作成する際に出力されたエラー
原因
NAT Gatewayの上限に抵触している。
対処
上限に達してしまっているので上限を増やす必要がある。
AWSコンソール上のサポートから問い合わせることで対処が可能
東京リージョンの「アベイラビリティーゾーン当たりの NAT ゲートウェイ上限数」を10へと変更することによって対応可能。
VPCを作成する際に出力されたエラー
NAT Gatewayの上限に抵触している。
上限に達してしまっているので上限を増やす必要がある。
AWSコンソール上のサポートから問い合わせることで対処が可能
東京リージョンの「アベイラビリティーゾーン当たりの NAT ゲートウェイ上限数」を10へと変更することによって対応可能。
ECRのリポジトリへimageをpushする手順を記載する
手元の環境にimageがあること(docker imageコマンドでimageが出てくること)
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE sumito_http latest 54f5e642e4ae 5 weeks ago 1.1GB
ECRにリポジトリを作成する
ECRへpush用のタグをつける
$ docker tag sumito_http 123456789.dkr.ecr.ap-northeast-1.amazonaws.com/dmp/sumito:latest
pushする
docker push 123456789.dkr.ecr.ap-northeast-1.amazonaws.com/dmp/sumito:latest
この際
“` no basic auth credentials “`
と表示される場合はログイン処理が必要になる
$ aws ecr get-login --no-include-email --region ap-northeast-1
表示されたコマンドを実施して
“` Login Succeeded “`
と表示されればOKだ。
再度pushするとContainer imageがECRに格納される
wordpressのユーザー一覧をgit管理したいことがある。
wpコマンドを使うことで実現可能だ。
$ /usr/local/bin/wp user list --path='/home/kusanagi/cms/DocumentRoot' +----+-------------------+-------------------+-------------------+--------------------+---------------+ | ID | user_login | display_name | user_email | user_registered | roles | +----+-------------------+-------------------+-------------------+--------------------+---------------+ | 1 | admin | admin | aaa@sumito.jp | 2013-09-04 01:30:4 | administrator | | 12 | design | design | bbb@sumito.jp | 2018-08-21 07:46:4 | editor | | 15 | ccc | ccc | ccc@sumito.jp | 2018-10-01 05:22:5 | ccc | +----+-------------------+-------------------+-------------------+--------------------+---------------+ $
あとは定期的にこの処理をcronのようにjobとして動かし、
gitへ通知すればスタッフの離職時の棚卸しなどが容易になる。
手動でログローテートを行いたい時があるので、その対応。
logrotate -d /etc/logrotate.d/syslog
-vオプションを追加すると詳細が表示される 手動実行する際は-fで実行する
logrotate -f /etc/logrotate.d/syslog
Datadogを使用していると、ログにアクセスできないパーミッションエラーが発生することがあります。このエラーは、Linuxで一般的なものです。解決するには、/var/log/syslogを参照できるようにする必要があります。
以下のコマンドを使用して、/var/log/syslogにアクセスできることを確認します。
# ls -l /var/log/syslog -rw-r----- 1 syslog admin 79639 Jan 2 9:09 /var/log/syslog
DatadogのエージェントのUID/GIDを確認し、セカンダリーグループ(admin)に追加します。グループを上書きしないように注意してください。
# id dd-agent uid=113(dd-agent) gid=118(dd-agent) groups=118(dd-agent)
仮に-aを忘れてしまうと、所属しているグループを上書きしてしまいます。
usermod -aG admin dd-agent
# id dd-agent uid=113(dd-agent) gid=118(dd-agent) groups=118(dd-agent),4(admin)
これで、Datadogからログを取得できるようになります。
2018年も99%が終わり今年を振り返る
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 99%
— Year Progress (@year_progress) December 28, 2018
インフラエンジニアをやっている。
それまで他社クラウドを使いIaaS型のクラウドを使って来たが、
データベースを含むメインの基盤をAWSに移行した。
これによりAWSマネージドサービスを使う事ができ、チームは学ぶべき知識と、得られる知識の領域が変わった。
IT業界全体を俯瞰して見てもAWS移行経験は需要だらけなので、本プロジェクトを通じて、とても貴重で重要な経験をさせてもらった。
DMP(Data Management Portal)を刷新すべく、そのプロジェクトリーダーをさせてもらっている。具体的にはBigQueryの活用。
プロジェクリーダーの経験は未経験だったし、今まで「稟議書ってなんスカ?」ってほど全くよくわかってなかった。
具体的にやっていることは目的を明確にし、タスクを整理し、人をアサインしプロジェクトを管理するという所。専任のメンバーはいないので、他のチームから1ヶ月あたり0.2人月ほどメンバーを借りてやっているが、
「ちょっと工数かけ過ぎているので、少し抑えてほしい」という話しをエンジニアをお借りしている所のリーダーから来たりするのでプロジェクトリードの難しさを痛感している。
レアジョブでは副業が認められている。
自分としては、当然メインの業務もあるし、家庭もあるしということで、積極的に仕事を探していた訳ではなかったが、声がかかった時にだけ副業をしている。
(ちなみに今まではインフラエンジニア養成のための勉強用資料作成、ならびにそれを用いたドットインストール風のvideoなど。フリーランス時代に担当してもらった営業さんからお願いされて、2017年〜2018年はじめに作った)
今やっている副業は、ご縁のある方から「手伝ってほしい」と言われたため、お仕事を受けた。
その会社の特徴として、インフラエンジニアのプロパーがいない。
業務委託のインフラエンジニアが週4で仕事をしている状態で、彼がガシガシ新しいプロダクトに合わせてインフラを作っていているので、運用がまだしっかり整備されていない。という問題があった。
どれだけ整備されていないかというと、論理構成図がない。
なので、GCP/AWSの管理画面に入り、Cacooで論理構成図を作っていく作業。
タイミングよくCacooで構成図の自動作成機能がリリースされたので、基本的にそれを利用。
https://cacoo.com/ja/blog/aws-architecture-import/
ただ、これを使っただけだと使い物にならないので、サービスとして使っている形に整理したり、その後はALBにログインしていき、どのポートで受け付け、どのサーバでどのポートで接続しているのかplotしていった。
ここでの得た事の一つは、
新規参画者には現在の環境の整理をお願いすると、新規参画者への教育コストを抑えつつ、環境を覚えてもらい、ドキュメントも綺麗になる。一度で三度ウマい方法。
自分のプロジェクトでもこれはやりたいと思った。
あとは第三者的にシステムの問題を洗い出し、タスク化し、お客さんと一緒に優先順位を決めていき、それに対する作業見積もりをして、あとはリモートで作業をしていく。
このような形で進めたいと提案し、お客さんに合意してもらった。
しかし、大前提となるのが”信頼関係”である。リモートなら尚更だ。
私に声をかけてくれた方と自分との間には”信頼関係”は既に構築されているが(信頼関係が構築された上で、声をかけてもらったのだが)、他のメンバーの方とは当然まだない。
どのように信頼関係を築いていくかは、一緒に仕事をしていく事が最短だと思っている。信頼関係がない上でのリモート作業は、お互いが不幸になるリスクがある。
その為、以下のアプローチをとった
redashのヘビーユーザーだったが、今年4本pull requestを出させてもらい、その全てがmergeされた
https://github.com/getredash/redash/pull/3041
CLIでuser一覧を表示さえる時に、ランダムに表示されてしまうが、A-Z順にソートされるようになった。
https://github.com/getredash/redash/pull/2951
redashのdisable機能はversion 5から導入された。しかしuserがenableなのかdisableなのかはCLIでは確認する方法がなかったので、その機能を追加した。
https://github.com/getredash/redash/pull/2967
CLIのuser一覧に所属しているgroupを表示させるようにした
https://github.com/getredash/redash/pull/2991
これも似たようなものだけど、CLIでgroup一覧を表示させた場合、そのgroupにどのユーザーが属しているのかわかるようにした。
ちなみにOSSへ貢献するとリポジトリを見てくれる方からメッセージをもらえる事がある
OSSへのコントリビュートは様々な選択肢を得ることに繋がるので、おすすめだ。
また、redash meetupでの登壇を2本。(登壇資料添付済み)
https://redash-meetup.connpass.com/event/85550/
https://redash-meetup.connpass.com/event/101420/
上記とは別にredashのコントリビュータの会合(redash meetup 4.0.1-dev、redash meetup 4.0.2-dev)をレアジョブで開催した。
今月はredash advent calendarで記事を3本書いた。
https://adventar.org/calendars/3299
最初はQiitaにアウトプットを書いていたけど、最近はQiitaは書かずwordpressにしている。
理由は以下の通り
今はBlogとしてまとまったことを書くというよりは、あくまでも仕事で使ったことの作業メモ置き場として使っている。
Blogを書いても書かなくても作業のメモは書くけど、それを自分だけで持っている理由はない。自分が困ってたことは、きっと他の誰かも困ってることかもしれないというという理由から始めた。
プライベートを定量的に2018年を振り返る。
TOEIC 750点 → 820点
トライアスロン(オリンピックディスタンス) 3時間5分→ 2時間58分
ベンチプレス 40kg → 70kg書ききれないほどいろいろあったけど、全てが最高。この1年やり直して達成感をもう一度達成感を味わいたいくらい最高に楽しい一年だった
— Sumito.Tsukada (@19840209) December 28, 2018
マラソンのベストタイム(3時間4分)から依然程遠い。
2013年に妻の妊娠を機に走るのを一時的に辞めたが、まだまだ当時の速さに戻れていない。
今年の目標は3時間30分切りを目標にしていたが、全てのレースで目標に届かなかった。
佐倉マラソン
https://connect.garmin.com/modern/activity/2577060920
長野マラソン
https://connect.garmin.com/modern/activity/2625723712
つくばマラソン
https://connect.garmin.com/modern/activity/3183514412
金沢マラソン
https://connect.garmin.com/modern/activity/3120745226
九十九里トライアスロン(オリンピックディスタンス)では、ベストタイムを出せたが
オリンピック選手の瀬戸大也選手にスイムでぶっちぎりで距離を付けられ、バイクとランで距離を詰める事ができなかった。
2018年は筋トレを始めたということもあり、run/bikeの時間を削った。最近は100km程度しか走れていない。
bikeは完全に通勤、帰宅として。寒くて心折れているのがグラフから読み取れる。
息子が4歳(3月に5歳)になるので七五三をやったが、fotowaというサービスを使いプロのカメラマンに来てもらったが、プロのクオリティに感動した。このことはfotowaのオウンドメディアに取り上げてもらった。
多くの方に支えられ、満足いく2018年を終えることができた。
去年より今年、今年より来年。と右肩上がりで成長できれば最高だけど、少なくともそれに近づけれるように2019年も過ごしたいと思う。
dockerを長期的に運用していると、気がついたらdiskがなくなってることがある。
# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda3 16G 14G 1.2G 93% /
気がつけば93%もう後がない状態。
dockerの不要なボリュームを削除することで対処可能
まずは使われていないdiskを確認する。
# docker volume ls -f dangling=true DRIVER VOLUME NAME local 0d0c5c35a033c3fbf35bc8eb3b1f9a9612ece1c622cf0ad357b6e20084350760 local 9aea772f64985c7a271f5d20c519b4a59ccd2219030f961c37a1cfb0130f2d35 local 55ccc89f56ebe15c4091cb4b196877ea08e9dd93ecb26fd17b941baf03458b58 local 93ef3cb97887f0d357332afbcebb5c096f7e8eaae4bcfd2285042e51d53771c7 local 529d774ed12a837ceb118b56ef16bd2ad9420973cd76f1a76575c21e9b0719ff local 543b74740c96e9925d66546fd56b2e8eb3e2254706c0ae10e37dfd54c3719033 local 635117bef58efbcaff9d0b8aab47702d2ad271bb5fffd4e0ab8f700e3d5aa2f5 local 069661160a320af109bccf5099d1f4b7f5a2003911ba8d029075c45b145873d1 local af62d09de828c78ed362278a8bda4120649dadb5e3d824e65c6309c0293d7d37 local c8e396a769f4c4e8a0829f9b230fec92b282b9b36575218d25b89bf9891349d5 local d190aecd81bc16520210af668c3ea0fec32a1b1a3d8554a058c5cef65f87de09 local dcd49f633c6c0fbb7307788cc1521b6cc9c851fdd52aab9f0af7687ed3a1ab3e local e0b22e274022a38e0aedbd6db1b950c3084d1f463e5f1a47b79d5e38d61e5bcb local e051a42bc994b73f704863559f818289a4c38ec6f314b99be365e9a6484ac604 local ebad853173f65bd381eb52f43493825a8e3e9c19bbaaa7dcfd6b03f39611cf4f #
不要なdiskがぞろぞろ出てくる。
パイプで繋いでxargsで削除。
# docker volume ls -qf dangling=true | xargs docker volume rm 0d0c5c35a033c3fbf35bc8eb3b1f9a9612ece1c622cf0ad357b6e20084350760 9aea772f64985c7a271f5d20c519b4a59ccd2219030f961c37a1cfb0130f2d35 55ccc89f56ebe15c4091cb4b196877ea08e9dd93ecb26fd17b941baf03458b58 93ef3cb97887f0d357332afbcebb5c096f7e8eaae4bcfd2285042e51d53771c7 529d774ed12a837ceb118b56ef16bd2ad9420973cd76f1a76575c21e9b0719ff 543b74740c96e9925d66546fd56b2e8eb3e2254706c0ae10e37dfd54c3719033 635117bef58efbcaff9d0b8aab47702d2ad271bb5fffd4e0ab8f700e3d5aa2f5 069661160a320af109bccf5099d1f4b7f5a2003911ba8d029075c45b145873d1 af62d09de828c78ed362278a8bda4120649dadb5e3d824e65c6309c0293d7d37 c8e396a769f4c4e8a0829f9b230fec92b282b9b36575218d25b89bf9891349d5 d190aecd81bc16520210af668c3ea0fec32a1b1a3d8554a058c5cef65f87de09 dcd49f633c6c0fbb7307788cc1521b6cc9c851fdd52aab9f0af7687ed3a1ab3e e0b22e274022a38e0aedbd6db1b950c3084d1f463e5f1a47b79d5e38d61e5bcb e051a42bc994b73f704863559f818289a4c38ec6f314b99be365e9a6484ac604 ebad853173f65bd381eb52f43493825a8e3e9c19bbaaa7dcfd6b03f39611cf4f #
93% -> 72%に削減できた
# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda3 16G 11G 4.3G 72% /
dockerの -f “dangling=true” はフィルタオプション。
“dangling=true” はどのコンテナにも紐付いていないボリュームを抽出する事が可能。
awsであればファイル置き場にS3を使うことも多いだろう。
s3への転送したい場合はaws s3 cpコマンドを使うことが多い。 似たようなことをGCPでCloud Storageに対して行いたいことがある。
ローカルからファイルをコピーする場合 gsutilコマンドを利用する
gsutil cp /tmp/hogehoge gs://bucket/dir/
削除する場合は
gsutil rm gs://bucket/dir/hogehoge
オフィシャル情報はこちら https://cloud.google.com/storage/docs/gsutil?hl=ja
ちなみにプログラム(Python)に組み込む際はこちら https://tsukada.sumito.jp/2018/11/20/gcp-python-cloud-strage-upload/
決まった時間に処理を行いたい時、cronを設定することが多い。しかし、時間を設定するとなぜかうまく動かない。ということが発生した。
0 0 * * * mkdir -p ~/Documents/Downloads/`/bin/date +%Y%m%d`
毎日0時0分にディレクトリを作りたい。
~/Documents/Downloads/配下に日付ディレクトリを作りたかったが、うまく動かなかった。
macでは%は区切り文字として認識されてしまう。 そのため、%の前では¥でエスケープしてあげる必要があることがわかった。
0 0 * * * mkdir -p ~/Documents/Downloads/`/bin/date +\%Y\%m\%d`
Linuxでは必要ないが、macでは必要らしい。 これで期待通りディレクトリが作成されるようになった。
メリークリスマス⛄️
本記事はredash advent calendarの12/24の記事です。
redashはさまざまな人が使うツールへと発展してきました。
それに応じてredashは常に安定稼働していなければならない必要性も高まってきています。
redashの状態監視がますます必要な状態になりました。
redashの監視といえば、status.jsonというものがあります。
https://kakakakakku.hatenablog.com/entry/2017/12/21/025718
これを使えば、いまredashがどれだけのクエリが保存されていて、memoryを使っていて。。。ということがわかるのですが。。
しかしある時、API経由で使っている人が「redashの返すクエリの結果が変わらないんだけど。。。」という問い合わせを受けました。
redash自体ハングしていたら、この状態はstatus.jsonではわからないのです。
redashが”機能的に正常に動いているのか、監視する必要がでてきました。
“機能的に”動いているかを確認したいのであれば、”機能的に”監視するのが一番。
redashでは単純に現在時間を返すクエリを登録します
SELECT to_char(now() + interval '9hour' , 'YYYY/MM/DD HH24:MI:SS');
データソースはredashの持つpostgresにしました。
redashを監視サーバからAPIで叩きに行き、
前回実行した時間を差分を取るという仕組みです。
前回と違う結果だったら問題なし。同じ結果だったら”異常”とみなす。
監視サーバには以下のシェルを置きました。
# cat ./redash_monitor.sh #!/bin/bash # redashに問い合わせ(cache clear) $(curl -s https://redash-url.jp/api/queries/309/refresh?api_key=HoZrcikN0uhqNnaAPUtHKhogehogehogehoge -X POST > /dev/null ) sleep 30; # 現在の値を取得 curl -s https://redash-url.jp/api/queries/309/results.json?api_key=HoZrcikN0uhqNnaAPUtHKhogehogehogehoge | jq -r '.query_result.data.rows[].to_char ' > /tmp/monitor.txt.tmp # 差分を比較する。差分があれば通知。 diff /tmp/monitor.txt.tmp.previous /tmp/monitor.txt.tmp if [ $? -eq 0 ]; then # 文字を整形する # headder cat << _EOT_ > /tmp/msg.txt [info] [title] Redash might not work well [/title] Oh my Gush!! Your redash might not work well [/info] _EOT_ _roomid=1234567890 _body=`cat /tmp/msg.txt` curl -X POST -H "X-ChatWorkToken: 9aaefddccc40hogehogehogehoge" -d "body=${_body}" "https://api.chatwork.com/v2/rooms/${_roomid}/messages" fi mv /tmp/monitor.txt.tmp /tmp/monitor.txt.tmp.previous
我々の環境はchatworkを使っているので、宛先はchatworkになっています
これをcronに登録し定期的に実行するようにしています。
大活躍する機能。と思いたいけど実はredash自体が優秀なためそれほど日の目を見る事はないのです。。
だけどこの監視を設定していると、いち早くredashの不具合に検知することができます。
ちなみにredashがおかしくなったら、serverやworkerコンテナを消してもう一度作り直すのが多いです。
明日は @ariarijp さんによる記事です!
https://adventar.org/calendars/3299#list-2018-12-25