投稿者: sumito.tsukada

  • GitLab Connection to gitlab.com timed out. (connect timeout=5)’))

    GitLab Connection to gitlab.com timed out. (connect timeout=5)’))

    はじめに

    GitLabに接続する際、

    GitLab Connection to gitlab.com timed out. (connect timeout=5)'))

    のように表示されることがある

    原因

    接続元が同しIPの接続元から、gitLabに複数回アクセスしたものの認証に失敗した。

    しかし、なんどもログイン失敗したため、接続元のIPを自動でプラックリストに入ってしまったことが原因

  • Baseimage-dockerとは

    Baseimage-dockerとは

    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 を動かしたりしている。

    Debug方法

    Baseimage-dockerのiniプログラムを実行させず、直接bashを起動は以下の通り

    直接コンテナに入ることができる。

    docker run --rm -it phusion/baseimage:master bash -l
  • Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    はじめに

    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 Directory Layout

    まず、Alternativeではない、正攻法(?)のDirectry Layoutは、以下のとおり

    Directry Layout

     

    これに対し、Alternative Directory Layout は Staging/Production が 明確に分かれているのが特徴だ

    Alternative Directory Layout

    双方のメリット・デメリット

    メリット

    productionとstagingがディレクトリが分かれているため 環境ごとに設定を変える事ができる。

    Directry Layoutの場合、productionとstagingがディレクトリが分かれていない。

    そのため、productionとstagingが全く同じ環境であればよいが、ランニングコストを下げるためにStagingのみ台数を減らしたり、パラメータを変更するようなことが柔軟にやりにくくなってしまう。現在のみならず、先々を考慮しこの構成を採用した

    デメリット

    ほとんどの設定ファイルがproductionとstagingで冗長してしまう

    結論

    上記デメリットがあるものの、Alternative Directory Layout を採用することによる享受できるメリットが判断し、このレイアウトを採用することにした。

  • error pulling image configuration: Get https://xxxx  : net/http: TLS handshake timeout

    error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    はじめに

    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 
    
    
  • NINE LIES ABOUT WORK 仕事に関する9つの嘘 を読んだ

    NINE LIES ABOUT WORK 仕事に関する9つの嘘 を読んだ

    背景

    チームリーダーとして仕事をする上で、自分のやり方が正しいのか、ルールがおかしいのかよくわからなくなることが多々ある。

    その度にマネジメント系の本を頼ったりしていたが、今回同僚にこの本を勧められたので自分も買ってみた。

    8つの質問

    この本では、最も業績の高いチームにとくに多くみられた従業員経験の側面があり、それを正確に表現した質問事項が以下の8つあがっている。

    • 会社の使命に貢献したいと思っているか
    • 仕事で「自分に期待されている事」とはっきり理解しているか
    • 所属チームでは「価値観が同じ人」に囲まれているか
    • 仕事で「強みを発揮する機会」が毎日あるか
    • 自分に「チームメイトがついている」と思えるか
    • 「優れた仕事」をすれば認められることをしているか
    • 「会社の未来」に自信を持っているか
    • 仕事で常に「成長」を促されているか

    目標設定について

    登場人物のひとりとして、よくマラソンを目指す友人という話しがでるので、自分ごとのように読んだ。

    目標が役立つかどうか、自発的に設定したかどうか。全体目標から落とし込まれた目標は、本当の目標ではない。

    最高の企業は目標を落とし込まない。最高の企業は「意味」を落とし込む。

    チームメンバーには外の世界で起こっていることを理解させるとともに、どの山を目指しているのかを伝える。

    「意味」と「目的」がわかれば人は動く。

    貢献するための具体的な方法はチームメンバーに任せるべきだ。

    もっと突き詰めれば「共通の目標」があってもまとまらず、チームメンバーのために本当に重要な仕事の意味と目的、使命と貢献、手法を吹き込むことと説いてある。

    チームリーダーの役割

    チームリーダーの役割は、チームとしてのアウトプットを最大化し、メンバーには手鏡を与えることである。

    ビジネス感覚を持った人とはどんな人か

    ビジネス状況を理解して決断を示す機敏な速さのことであると説いてある。

    ビジネス感覚を持つ人は、状況に関する重要な情報を取得、主要目標に集中し、問題解決のために取り得る妥当な対応策を認識し、適切な行動指針を選ぶこと。それができる人のことだ。

    人は訓練を積んでも、他人を正しく評価できるようにはならないと本書では伝えている。

    その状況に対してどうすればいいか。

    評価に使う良いデータと悪いデータを識別する方法を学ぶことからはじめる

    答えではなく、問いを模倣せよ

    本書を乱暴にたった一行でまとめるとすればこんな感じだ。

    本ブログでまとめたのはごく一部だが。目から鱗が落ちるところが多々あった。

  • n日前のファイルを削除する

    n日前のファイルを削除する

    ファイルのローテーションをするために処理を書くことがある、find コマンドの -mtime オプションを使うが、このようなニーズでないと使わないのでメモ。

     find /home/hoge/backup/* -mtime +7 

    7日前のファイルが表示される。

    xargs コマンドと合わせて削除をする。

    find /home/hoge/backup/* -mtime +7 | xargs rm -f

  • ecr get-login を使わずコンテナを ECR に push する

    ecr get-login を使わずコンテナを ECR に push する

    今までは

    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

    これは便利なので活用していきたい。

    参考情報

    https://qiita.com/r_plus/items/41fb31285fb64fb4be85
  • ピープルウエア を読んだ

    ピープルウエア を読んだ

    読んだ動機

    業務をしていたプロジェクトリーダーを努めさせてもらった一年半の長い長いプロジェクトがようやく終わりを迎える。

    振り返ってみたら、不確実性との戦いだった。手探りにプロジェクトを進め、ひっくり返ることもあった。

    不確実性との戦いは今回担当したプロジェクト特有のものではない。おそらくきっと、人生につきまとってくるもののひとつだ。

    それであればこの機会に不確実性についての取り扱いについてきちんと学びたいと思うに至った。

    そこで ヒロキさんの Qiita にたどり着いた。

    https://qiita.com/hirokidaichi/items/95678bb1cef32629c317#%E4%B8%8D%E7%A2%BA%E5%AE%9F%E6%80%A7%E5%88%86%E6%9E%90%E3%82%AF%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AB%E3%83%AB%E3%83%91%E3%82%B9

    トム・デルマコの著書はとてもいい知見に溢れているものの、自分からしたら比喩がわかりにくいこともあり、あまりすすんで読もうとはしてこなかったが、

    知見を得たいとの一心で久しぶりに トム・デルマコ本。 ピープルウエア を読むことにした。

    学んだこと

    一言で言うと、この本は不確実性を直接対処するものではなく、生産性の高いチームを育てることで不確実性にも対応できるようにするといった本だ。

    管理者が陥りやすい錯覚

    個人的にはここで挙げられている項目が現在の自分が考えていた感覚とドンピシャだった。

    7つ記載があったが、その中の3つがとても良かった。

    • 生産性を飛躍的に向上させる方法があるはずだが、見落としてきた
      上記錯覚に対する反論として以下が挙げられていた
      基本的なものを見逃すものはない。
      新しい方法を求め努力してきた。これからやろうとしている情報のどれもが、実際に生産性を高めることはない。
      人は、何かに熱中したり、学んだり改善したりと思っているものである。

    • 他の管理者は自分より、2倍、3倍の成果を上げている
      この錯覚に対する反論は以下のとおり。
      そんなこと気にすることはない。開発やテストの部分に照準を合わせているに過ぎない。
      他にもドキュメント作ったり、顧客と折衝したりする必要がある。
      小さな視点で人と比べるのは良くない。

    • バックログが多いから生産性をあげなければならない。
      プロジェクトの完成時にコストを計算すると、当初予算を遥かに上回るのが常識。
      開発資金がなかった為に完成できなかったから、バックログになったもの。
      生産性の向上は、バックログをこなすために必要なのではない。
      バックログに溜まったタスクを潔く捨ててしまうことで得られる。
      (わかるけどこれはちょっと極端だ)

    生産性の高いチームを育てる

    人が楽しいと思える仕事に必ず「挑戦」がある。

    挑戦はチームのメンバーが一緒になって努力する目標が与えられるからこそ必要になる。挑戦は時にチームを一つにまとめる道具になる。最良の仕事仲間を持った時、人は愉快な気分になるものだし、力を尽くす。その時チームの相互作用がフルに働く。この瞬間、メンバーも楽しいと感じる。

    チームが結束し始めると、成功の確率はぐんと高まる。このフェーズに入ったチームを率いることはリーダーとしての楽しみにもなるようだ。

    結束の強いチームの特徴として、退職率の低さがある。

    自己防衛を取ることのリスク

    チーム編成を妨げ、プロジェクトを崩壊させる確実な方策与えられた仕事をこなす能力が部下にない場合、プロジェクトは失敗する。
    しかし、与えられたグループでやっていこうと一旦決めたなら、最良の戦術は部下を信頼すること。
    部下を信頼する代わりに、プロジェクトの成功を保障しようとして自己防衛の手段をとれば事態は悪化する。

    最良の上司の定義

    「管理」などないかのように、チームが和やかに一致団結働かせることができる人。

    管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人。

    健全な会社にするための戦略的要素

    • 品質を高める
      チームのメンバーが品質至上主義になると、市場が求めている以上の品質が備えた製品を常に生産するようになる。
    • 満足感を与える打ち上げ
      (コロナ禍なので飲み会は難しいけど、自分の担当プロジェクトが完遂しら何かしないとな。)

    読み飛ばしたところ

    この本が書かれた時と時代は変わり、リモートワークが定着したことでオフィスに全員が出社する頻度はかなり減った。本書ではオフィスの環境についても書かれてあったが、そこはざっと読んだだけで、ほとんど読み飛ばした。

    ここの部分はリモートワークについて語ってる Youtube大学で語っていることを取り入れることにした。

    まとめ

    時代は変わってもチームビルディングについてのポイントは変わってない。

    名著から学ぶことは多い。

  • Model name must be alphanumeric:

    Model name must be alphanumeric:

    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'