AnsibleでFailed to connect to the host via ssh: Permission deniedのエラーが出たとき

概要

AnsibleでFailed to connect to the host via ssh: Permission deniedが出た。

$ansible all -i inventory -m ping
host | UNREACHABLE! => {
    "changed": false, 
    "msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 
    "unreachable": true
}

環境

$ansible --version
ansible 2.6.8

対応

パスワードレスsshできるように公開鍵を対象ホストに設置した。
チェックポイント

  • パスワードレスssh接続できるか試す
  • ansible all -i inventory -m pingコマンドを試す

対応後のレスポンスはこうなる。

$ansible all -i inventory -m ping
host | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

AnsibleホストでAnsibleを実行するユーザと、リモートホストで作業するユーザを考慮する。

c.f. https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html#id5

2018年後半ふんわりまとめ

2018年前半まとめ（一部） - mMQnaZ7vL2DWkoU’s diary

続き

8月からチーム移動があった。
後半はざっくりまとめる。  

やっていること

  • レガシープロダクトの引き継ぎ*4
    プロダクトの分析
    改善点の洗い出し  
  • Domain Driven Develpomentでのリプレイス開発*1
    エヴァンス本の勉強会
    旧仕様のユビキタス言語の洗い出し
  • 新チームでのスクラムイベントの導入  
  • 新人教育  

 

チケット化したものの一部

  • ログ基盤の構築
  • アクセス解析の導入
  • パフォーマンスモニタリングの導入
  • テスト自動化
  • テストピラミッドによるテストレベルの分離
  • CI/CDフローの改善
  • バグをいくつか発見したのでそれの改善
  • Promise hellの改善
  • linter,formatterの導入
  • ローカル開発環境の構築
  • インフラ周りの負債返却
  • ブランチ運用の改善  

 

個人でやっていたこと 

  • GolangでCLIツール作った
    QiitaAPIを使った。
  • Ansibleの理解を深めた
    ベストプラクティス、テスト、CI/CDフローなど。
  • JAWS-UG 金沢でしっかりめの登壇
  • Kanazawa.rbでLT

以上。

後半もいろいろ学ばせてもらった。
来年もやっていきたいと思います。

2018年前半まとめ（一部）

メモ

JIRAで管理されたタスクから2018年を振り返ってみる。
チケット化されたもののみ書き出してみると、意外と作業量にばらつきがある印象だった。
ISSUEをチェックしようと思ったら前チームのGitHubEnterpriseのOrgから抹消されたので、過去のISSUEが見れなくなってた…

1月

  • Kibanaによるログの可視化
  • Chatops(Slack)によるAWSリソースの操作 これによりリリース作業が簡単になった。
  • jmeterによる負荷試験。手順に従って実施したので記憶が薄い
  • node-poolのリソース開放エラー調査
  • CloudFormatioinテンプレートの更新
  • Node.jsのバージョンアップ

など

2月

  • 障害報告/クローズ基準のまとめ作成
  • 軽微障害の復旧報告用テンプレート作成 Slackのslashコマンドで呼び出せるようにした。
  • CodeDeployのデプロイロールバックのSlack通知
  • 社内npmレジストリの構築（依頼してリポジトリの挙動確認）

など

3月

  • lint-stagedの導入
  • ESLintのルールの見直し
  • 社内npmのパッケージ移行
  • 内製パッケージのバージョニングのフローを考える

など
パッケージ移行やルールの変更作業など、地道な作業が多かった。

4月

  • 新規ページの実装
  • VisualRegressionテストの導入検討
    BackstopJSとかreg-suitとか触った
  • E2Eテストの改善

など

5月

  • Amazon API Gatewayの実装
  • StatusCakeによる外形監視の導入
  • 新規機能のデータストアの設計
  • 新規機能のデータ保存フローの検討
  • 新規機能のデータ量の見積もり

など

6月

  • 新規機能の外部API利用フローの設計作業
  • AWS Cost Explorerを使ったAWS利用料金のSlack通知

など

DockerfileのWORKDIRに$HOMEと書いても認識されない

Docker

環境

$docker --version
Docker version 18.09.0, build 4d60db4

概要

DockerfileのWORKDIRはDockerfileのENVで定義された環境変数しか使えないので下記の２点を考慮する。

ドキュメント

https://docs.docker.com/engine/reference/builder/#workdir

You can only use environment variables explicitly set in the Dockerfile.

build結果

build失敗して気づくパターン

$HOME単体ならbuild失敗して気づける

Dockerfile

FROM alpine
WORKDIR $HOME

docker buildの結果

…
Step 2/5 : WORKDIR $HOME
cannot normalize nothing

build成功して気づかないパターン

定義されていない環境変数＋パスが含まれているとbuild時に気づけないので注意
Dockerfile

FROM alpine
WORKDIR $HOME/hoge
RUN pwd

docker buildの結果

Step 3/3 : RUN pwd
 ---> Running in 81645314a99f
/hoge
Removing intermediate container 81645314a99f
 ---> 1f8259c44e59
Successfully built 1f8259c44e59

チーム移行するときに抑えておくべきポイント

概要

チーム移行するときに抑えておくべきポイントをまとめる
システムによって特性は異なるので優先順位や、必要かどうかは変化する

チェックすべきポイント

リポジトリを事前に見せてもらう

これから関わるプロダクトがどういうものか？事前に確認する必要がある。

ナレッジが管理されているか？

チームで活動していく上で必要なドキュメントが揃っているか？更新されているか？参照しやすい・検索しやすい状態になっているか？

各種図が存在するか？更新されているか？

システム構成図、ER図、クラス図、サーバ一覧などがあるか？
pngなど編集できないようなファイル形式で作らない。
ない場合は、システムの理解や問題発見につながるので早めにつくる。

セキュリティ対策できているか？

基本的なセキュリティについて、対策できているならその理由をまとめておく。
対策できていない場合は、ユーザやシステムに被害が出ないように最優先で対応する。

障害は検知できているか？

障害が起きてもわからないという状況をさけるため、障害検知は優先的におこなうべき。

ログ集約・監視はしているか？

「サーバ入ってファイルを見る」のような運用は辛いので、ログ集約・監視はやっておきたい。

パフォーマンスモニタリングできているか？

自分たちのシステムは、普段どれくらいのリクエストが来るか？CPU・メモリ利用率はどれくらいの値か？把握しておくべき。
パフォーマンスの異常を検知することで、障害の早期発見・事前解決につながる。

テストは書いてあるか？

単体テスト、結合テスト、統合テストは書いてあるか？

テストが充分でないと起こる不都合について

  • 単体テストの中で外部APIを呼び出したり、DB処理をおこなっているケース
    APIのテスト、DB処理のテストは必要だが、単体テストの中でおこなうと、テスト失敗の原因が分かりづらくなったり、単体テストに時間がかかるので分けるべき。
    さらにこのようテストをCI上でおこなうと、API呼び出しのためのトークンの登録なども必要になってくる。
  • 単体テストが書いていないケース
    コード変更の影響範囲がわかりづらい、結合テストが書いていないので検証に時間と労力がかかる。

CI・CDフローは整っているか？

自動テスト、自動デプロイできるようになっているか？
なるべく短い期間でデプロイするのが理想なので、デプロイに時間がかかったり、ミスが起きやすいフローになっている場合は修正する。

まとめ

これらの問題に対してチーム全体で話し合い、システムがどのような状況なのか？どこまでできるようにするのか？認識を合わせておく必要がある。
そうしないと、開発チーム間で認識の不一致が起きてしまう。

Qiita記事をローカル管理するツールが入門としてよかった話

Golang

概要

Goの入門としてQiitaをローカル管理するツールを作った。
リポジトリは以下。
https://github.com/ma-bo-do-fu/qsync
今回はその感想をメモしておく。対象読者はGo言語やツール開発初心者。

環境

$go version
go version go1.10.3 darwin/amd64

モチベーション

  • Goの練習したい
  • Qiita記事をGithub管理したい
  • ドキュメント管理をCIに載せたい

作ったもの

詳細は下記参照。
https://github.com/ma-bo-do-fu/qsync/blob/master/README.md
概要だけ記載する。

$qsync pull

すべての投稿を指定した場所に保存する。

$qsync push /path/to/entry

保存した投稿を更新する。

$qsync post

新規に投稿する。

入門としてよかった点

題材が練習としてちょうどよかった。 今回のツールを通して以下の処理について学ぶことができた。

  • APIクライアント
  • josnやyamlのエンコードとデコード
  • 文字列操作
  • ファイル読み書き
  • 日付操作

問題点

画像添付できない

画像添付用のAPIがないので画像が添付できない状態。
運用としてローカルで画像保存用のディレクトリ(例：YYYY/mm/dd/images)を作ってそこで管理し、記事公開時に改めてブラウザ側で添付するなどか…
Qiitaの画像はS3で管理されているので、

$qsync attach 記事ID /path/to/image

とかでS3のURLが返ってきたらローカルで作業が完結できそう。

マークダウンの表示が異なる

VSCodeのマークダウンプレビューととQiitaの編集画面とで表示が異なる。 結局微調整のためにブラウザで編集することに…

感想

  • テストを書かずに開発するのはつらい
    とりあえず動くものを作ろうとテストを書かずに開発したら苦労した。次はテストの書き方を覚える予定。
  • 毎回go build/go installをするのが大変
    コード変更したら自動でビルドとインストールが走るようにしたい。
  • プロジェクトの名前が被っていた
    ツールを作るときはGoogleとGithubで検索して被っていないか調べたほうが良い。
  • rangeの書き方が馴染んだ
    tour of goをやっているときにrangeの書き方に戸惑ったが、ツールを書いていたら馴染んだ。
  • gometalinterを早めに入れればよかった
    linterは開発初期から入れるべき。後から入れると修正が大変。
  • ちゃんと設計しないと後からつらくなる
    README駆動開発という言葉もあるように、最初に要件定義を書くと全体の見通しが立ちやすいと思う。

何かのサービスのAPIクライアントを作るのは、その言語に初めて触れるときに良い練習になると感じた。 新しい言語を学びたいけど作るものに困っている方はAPIクライアントにチャレンジしてみるとよいかもしれない。

php artisan migrateでautoload.phpがなくて失敗する

PHP

環境

$ php -v
PHP 7.1.10 (cli) (built: Aug 22 2018 18:45:08) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans

発生したエラー

$php artisan migrate

Warning: require(/var/www/app/bootstrap/../vendor/autoload.php): failed to open stream: No such file or directory in /var/www/app/bootstrap/autoload.php on line 17

状況

  • /var/www/app/bootstrap/../vendor/autoload.phpが存在しない
  • vendor/は存在する

原因究明

$composer install -vvv

とすることでcomposer installのデバッグログが見れる。
すると下記のようなエラーが（docker-comopseで実行していた）

app_1    | 
app_1    |                                                                 
app_1    |   [RuntimeException]                                            
app_1    |   /var/www/app/vendor does not exist and could not be created.  
app_1    |                                                                 
app_1    | 
app_1    | Exception trace:
app_1    |  () at phar:///usr/bin/composer.phar/src/Composer/Util/Filesystem.php:186

解決方法

プロジェクトルート（今回は/var/www/app/）に書き込み権限を与えて解決