はじめに
GitLabに接続する際、
GitLab Connection to gitlab.com timed out. (connect timeout=5)'))
のように表示されることがある
原因
接続元が同しIPの接続元から、gitLabに複数回アクセスしたものの認証に失敗した。
しかし、なんどもログイン失敗したため、接続元のIPを自動でプラックリストに入ってしまったことが原因
GitLabに接続する際、
GitLab Connection to gitlab.com timed out. (connect timeout=5)'))
のように表示されることがある
接続元が同しIPの接続元から、gitLabに複数回アクセスしたものの認証に失敗した。
しかし、なんどもログイン失敗したため、接続元のIPを自動でプラックリストに入ってしまったことが原因
docker は 1コンテナ 1プロセスで動かすという思想のもと作られているが、普通のコンテナ思想のもと作られたコンテナではない。
ssh でログインすることもできるし、 cron も動かすこともできる。
supervisorなどのプロセスコントロールシステムを使えば複数プロセス起動させることもできるので、この仕組みを使っているちょっと変わった 80M 程度の軽量なコンテナだ。
利用方法は以下の通り。まずは pull
docker pull phusion/baseimage:master
docker run --rm -it phusion/baseimage:master
Baseimage-dockerのiniプログラムが実行される。
ctrl + cで抜ける事ができる
この ini 処理で supervisor が動き、そのプロセスの中で ssh を受け付けたり, cron を動かしたりしている。
Baseimage-dockerのiniプログラムを実行させず、直接bashを起動は以下の通り
直接コンテナに入ることができる。
docker run --rm -it phusion/baseimage:master bash -l
Ansibleで環境を作ろうと思えば、Ansibleのディレクトリ構成をどのような作り方もできてしまうが、Ansibleのbest practicesのAlternative Directory Layout (https://docs.ansible.com/ansible/2.5/user_guide/playbooks_best_practices.html#alternative-directory-layout )を元に構成を作ることにした
まず、Alternativeではない、正攻法(?)のDirectry Layoutは、以下のとおり
これに対し、Alternative Directory Layout は Staging/Production が 明確に分かれているのが特徴だ
productionとstagingがディレクトリが分かれているため 環境ごとに設定を変える事ができる。
Directry Layoutの場合、productionとstagingがディレクトリが分かれていない。
そのため、productionとstagingが全く同じ環境であればよいが、ランニングコストを下げるためにStagingのみ台数を減らしたり、パラメータを変更するようなことが柔軟にやりにくくなってしまう。現在のみならず、先々を考慮しこの構成を採用した
ほとんどの設定ファイルがproductionとstagingで冗長してしまう
上記デメリットがあるものの、Alternative Directory Layout を採用することによる享受できるメリットが判断し、このレイアウトを採用することにした。
docker pullした際、以下のような TLS handshake timeout
が発生
# docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ...
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pulling fs layer
1607093a898c: Pulling fs layer
9a8ea045c926: Pulling fs layer
1290813abd9d: Waiting
8a6b982ad6d7: Waiting
abb029e68402: Waiting
8cd067dc06dc: Waiting
1b9ce2097b98: Waiting
d6db5874b692: Waiting
25b4aa3d52c5: Waiting
53ec227dabf0: Waiting
242938ace8b4: Waiting
85bc5aaf4ec5: Waiting
fd5b749ebe99: Waiting
6636846685ec: Waiting
error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/9a/9ae2dde61ad6947df46e2cc416be9249f314d187feb717f6e18c0dc9a46bf5bf/data?verify=1538549397-3vZspNti03KIKxRXPmQsQeUbucI%3D: net/http: TLS handshake timeout
#
docker login
# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username:
Password:
Login Succeeded
#
一度ログインすると、その後取得が可能になる
# docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ...
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pull complete
1607093a898c: Pull complete
9a8ea045c926: Pull complete
1290813abd9d: Pull complete
8a6b982ad6d7: Pull complete
abb029e68402: Pull complete
8cd067dc06dc: Extracting 7.242 MB/122.1 MB
1b9ce2097b98: Download complete
d6db5874b692: Download complete
25b4aa3d52c5: Download complete
53ec227dabf0: Download complete
242938ace8b4: Download complete
85bc5aaf4ec5: Download complete
fd5b749ebe99: Download complete
6636846685ec: Download complete
チームリーダーとして仕事をする上で、自分のやり方が正しいのか、ルールがおかしいのかよくわからなくなることが多々ある。
その度にマネジメント系の本を頼ったりしていたが、今回同僚にこの本を勧められたので自分も買ってみた。
この本では、最も業績の高いチームにとくに多くみられた従業員経験の側面があり、それを正確に表現した質問事項が以下の8つあがっている。
登場人物のひとりとして、よくマラソンを目指す友人という話しがでるので、自分ごとのように読んだ。
目標が役立つかどうか、自発的に設定したかどうか。全体目標から落とし込まれた目標は、本当の目標ではない。
最高の企業は目標を落とし込まない。最高の企業は「意味」を落とし込む。
チームメンバーには外の世界で起こっていることを理解させるとともに、どの山を目指しているのかを伝える。
「意味」と「目的」がわかれば人は動く。
貢献するための具体的な方法はチームメンバーに任せるべきだ。
もっと突き詰めれば「共通の目標」があってもまとまらず、チームメンバーのために本当に重要な仕事の意味と目的、使命と貢献、手法を吹き込むことと説いてある。
チームリーダーの役割は、チームとしてのアウトプットを最大化し、メンバーには手鏡を与えることである。
ビジネス状況を理解して決断を示す機敏な速さのことであると説いてある。
ビジネス感覚を持つ人は、状況に関する重要な情報を取得、主要目標に集中し、問題解決のために取り得る妥当な対応策を認識し、適切な行動指針を選ぶこと。それができる人のことだ。
人は訓練を積んでも、他人を正しく評価できるようにはならないと本書では伝えている。
その状況に対してどうすればいいか。
評価に使う良いデータと悪いデータを識別する方法を学ぶことからはじめる
答えではなく、問いを模倣せよ
本書を乱暴にたった一行でまとめるとすればこんな感じだ。
本ブログでまとめたのはごく一部だが。目から鱗が落ちるところが多々あった。
ファイルのローテーションをするために処理を書くことがある、find
コマンドの -mtime
オプションを使うが、このようなニーズでないと使わないのでメモ。
find /home/hoge/backup/* -mtime +7
7日前のファイルが表示される。
xargs
コマンドと合わせて削除をする。
find /home/hoge/backup/* -mtime +7 | xargs rm -f
今までは
aws ecr get-login --no-include-email --region ap-northeast-1
のコマンドで ECR に login して container を push することができたが、
近年上記コマンドが実行できなくなってしまった。
代替コマンドとして get-login-password
を使うことでログインができる
aws --profile stg ecr get-login-password | docker login --username AWS --password-stdin https://123456789.dkr.ecr.ap-northeast-1.amazonaws.com
Login Successeded
となれば成功だ
たまに使うんだけど、順番を毎回ググって確認していた 2>&1
というリダイレクト処理がある
いままで
command >> word 2>&1
という書き方で、標準出力、標準エラー出力をリダイレクトしてきたが、
実は bash 4.0 から以下のような記載ができるようになったようだ。
command &>> word
man コマンドで bash を見ると以下のような記載がある
The format for appending standard output and standard error is:
&>>word
This is semantically equivalent to
>> word 2> &1
https://www.gnu.org/software/bash/manual/html_node/Redirections.html
これは便利なので活用していきたい。
参考情報
業務をしていたプロジェクトリーダーを努めさせてもらった一年半の長い長いプロジェクトがようやく終わりを迎える。
振り返ってみたら、不確実性との戦いだった。手探りにプロジェクトを進め、ひっくり返ることもあった。
不確実性との戦いは今回担当したプロジェクト特有のものではない。おそらくきっと、人生につきまとってくるもののひとつだ。
それであればこの機会に不確実性についての取り扱いについてきちんと学びたいと思うに至った。
そこで ヒロキさんの Qiita にたどり着いた。
トム・デルマコの著書はとてもいい知見に溢れているものの、自分からしたら比喩がわかりにくいこともあり、あまりすすんで読もうとはしてこなかったが、
知見を得たいとの一心で久しぶりに トム・デルマコ本。 ピープルウエア を読むことにした。
一言で言うと、この本は不確実性を直接対処するものではなく、生産性の高いチームを育てることで不確実性にも対応できるようにするといった本だ。
個人的にはここで挙げられている項目が現在の自分が考えていた感覚とドンピシャだった。
7つ記載があったが、その中の3つがとても良かった。
人が楽しいと思える仕事に必ず「挑戦」がある。
挑戦はチームのメンバーが一緒になって努力する目標が与えられるからこそ必要になる。挑戦は時にチームを一つにまとめる道具になる。最良の仕事仲間を持った時、人は愉快な気分になるものだし、力を尽くす。その時チームの相互作用がフルに働く。この瞬間、メンバーも楽しいと感じる。
チームが結束し始めると、成功の確率はぐんと高まる。このフェーズに入ったチームを率いることはリーダーとしての楽しみにもなるようだ。
結束の強いチームの特徴として、退職率の低さがある。
チーム編成を妨げ、プロジェクトを崩壊させる確実な方策与えられた仕事をこなす能力が部下にない場合、プロジェクトは失敗する。
しかし、与えられたグループでやっていこうと一旦決めたなら、最良の戦術は部下を信頼すること。
部下を信頼する代わりに、プロジェクトの成功を保障しようとして自己防衛の手段をとれば事態は悪化する。
「管理」などないかのように、チームが和やかに一致団結働かせることができる人。
管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人。
この本が書かれた時と時代は変わり、リモートワークが定着したことでオフィスに全員が出社する頻度はかなり減った。本書ではオフィスの環境についても書かれてあったが、そこはざっと読んだだけで、ほとんど読み飛ばした。
ここの部分はリモートワークについて語ってる Youtube大学で語っていることを取り入れることにした。
時代は変わってもチームビルディングについてのポイントは変わってない。
名著から学ぶことは多い。
API gateway にinsert する際、エラが発生
Your API was not imported due to errors in the Swagger file.
Unable to create model for 'user_id': Model name must be alphanumeric: user_id
Unable to create model for 'staff_id': Model name must be alphanumeric: staff_id
これは正規表現でいうところの
[a-zA-Z0-9]+
のみ model name としての利用を許容しており、アンダースコア含めた名前は API gateway に許容されていないため。
swagger としては アンダースコアが利用可能なので、API gateway も許容してもらいたいところだ。。
以下のように対処する
paths:
/hoge:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
booking_deadline:
$ref: '#/components/schemas/hogeline'
components:
schemas:
Event:
type: object
properties:
hoge_line:
$ref: '#/components/schemas/hogeline'