あかいものログスマートフォン用の表示で見るあかいものログ2020-02-14MacのCLI環境の構築を自動化する前回、IDEをやめてvim-lspと独自コマンドに移行したことを紹介しましたが、あれだけだと少し問題があります。akaimo.hatenablog.jpPCを買い替えたときやクリーンインストールをしたときなどに同じ環境を簡単に構築することができないともう一度構築することが面倒になってしまい、インストールするだけで使えるIDEでいいやとなってしまいます。そこで今回はAnsibleを使ってCLI環境の構築を自動化したときに簡単に使えるように意識したポイントを紹介します。Ansible自体の使い方は紹介しませんので別の記事を参照してください。自動化したコードは以下のリポジトリで公開しています。github.comポイント以下のことを意識して自動化しました。詳細な手順が書かれたドキュメントを用意するできるだけ実行するコマンドを少なくするアップデートしやすくする別のOSでも動くようにする1つずつ紹介していきます。詳細な手順が書かれたドキュメントを用意するいくら自動化していても、どのように実行すればいいか忘れてしまうと構築することができません。自動化した直後は覚えていても時間が経てばほぼ確実に忘れます。そのため自動化のキック方法をREADMEなどに書いておくべきです。自動化に使っている依存ツール(今回であればAnsible)があればそれのインストール方法も書いておくと良いでしょう。その他にも前提条件があれば書いておきます。READMEだけで構築が完了する粒度を意識します。できるだけ実行するコマンドを少なくする完全な自動化は難しいところもありますが、できる限り自動化して少ないコマンドで構築が終わるようにします。このときにインストール対象に合わせていくつかのコマンドに分けることをオススメします。これをやっておくことで構築するときに、そのとき必要なものだけインストールすることができます。OSのアップデートなどで自動化が壊れたときにデバッグと修復が行いやすくなります。アップデートしやすくする構築後に新たな拡張をした場合、次に構築するときに追加した部分も反映されて欲しいです。そのためには自動化した部分を適宜アップデートする必要があります。アップデートするときに手間がかかるような状態だと面倒になり放置してしまい、最終的にはアップデートする必要があることを忘れます。これはもったいないのでアップデートしやすくしておきます。複数のタスクで読み込まれる項目はinclude_varsで別ファイルから読み込むregisterで変数にするを行いました。これを行うと定義が見やすくなるだけでなく、実行ログに項目が表示されるようになるためエラーとなった項目を素早く見つけることができます。各タスクにきちんとnameを定義しておくこともメンテナンス性の向上につながります。別のOSでも動くようにするインストールコマンドで各OSのパッケージマネージャを使うなど、OSごとに処理が分かれる部分がでてくると思います。1つの環境でしか動かさないのであれば問題ありませんが、CLI環境はOSによる差を吸収しやすい部分ですし、サーバーにインストールする可能性も考慮するとどのOSでも構築できるようにしておくと便利だと思います。OSによる分岐を行うには、タスクにwhenを追加しOSの判定をすれば良いです。'Darwin'と書けば判定できます。OSによる違いがたくさんある場合はOSごとにファイルを用意してincludeに対してwhenを使ってまとめて切り替えたりもできます。おわりに今回はCLI環境の構築を自動化するテクニックを紹介しました。CLI環境は自分に一番合った設定にカスタマイズできる反面、インストーラーやインポート機能のようなものはなく、再度構築するのに時間がかかったり最悪の場合は再現できなくなってしまうリスクもあります。このようなことにならないためにも自動化をしておくことがオススメです。自動化しておくことでサーバーで作業するときにも気軽に同じ環境を構築できパフォーマンスもあがります。脱IDE先日メインで使っているマシンを修理にださなければいけなくなり、1週間ほど古いスペックの低いマシンを使うことになりました。Protocolの存在を思い出し使ってみることにしました。私はIDE以外で使っているエディタはvimのため、vim-lspを入れました。LSPLSPの説明や導入方法は他の記事に譲りますが、IDEが持っている言語に関する機能である関数や変数の補完、リネーム定義元や宣言元へのジャンプエラーやワーニングの表示フォーマットドキュメントの表示などがあり、基本的な開発なら問題なく行えます。実際に開発していると物足りなくなってくるいざ開発をしてみるとIDEでの開発と比較して不便なところがあります。プロジェクト内を対象としたファイル名とファイル内のテキストに対する検索が簡単にできないおおよその場所しかわからない目当てのファイルを見つけるのが遅いプロジェクト内の特定のファイルを対象にした任意のコマンドの実行が面倒これらを解決するためにCLI環境を整えたので紹介します。これから紹介する設定はGitHubで公開しているため、適宜参照してください。github.comプロジェクト内の検索これはIDEで最もよく使うコマンドと言っても過言でないぐらい頻繁に使うものなので、IDEと同じレベルのスムーズさが欲しいところです。簡単なコマンドで検索を開始してプレビューを見ながら選択し、選んだファイルをエディタで開きたいです。そこで高速な検索を行えるripgrepとCLIでインクリメンタルに曖昧検索ができるfzfを導入することにしました。CLIで曖昧検索をするツールは他にも存在しますが、fzfはvimから使うことができるのとプレビュー機能があることからfzfにしました。以下のような設定をするとIDEのような検索が行えます。:Buffer<CR>これでIDEのような検索が行えるようになりました。基本的にはIDEと同等の速度でスムーズに使えますが、プロジェクトが巨大になると検索に時間がかかるようになりCPUの負荷が高まります。これはインデックスされたものから検索しているIDEには敵いません。vim以外からも使えるようにするこの検索はただのコマンドの組み合わせなのでvimを経由しなくても使うことができます。以下のようにzshrcに書くと、検索ワードに引っかかったファイルをプレビューで見ながらインクリメンタルに絞り込みできます。fi}このスクリプトだとlessで開いていますが、vimで開くようにするなどカスタマイズ次第では無数のつなげ方ができると思います。場所しかわからないファイルを見つけるすべてを把握できていないプロジェクトでは、「名前はわからないけどあそこらへんにあったファイルを見たい」ということが稀にあります。このようなときのためにツリー表示をすることができるプラグインを入れています。基本的にはfzf経由でファイルを開くためツリーはオフにしておき、困ったときだけトグルでオンにしています。github.com特定のファイルを対象にしたコマンドの実行が面倒IDEでは開いているファイルやツリー上のファイルをクリックして何かしら便利なコマンドが実行できたりします。vimにはそのような機能はなく、新たにプラグインを入れるか別のターミナルから同等のコマンドを実行する必要があります。機能ごとにプラグインを入れるのも複雑になるため、ターミナルで同等のコマンドを実行することが多くなります。この場合、目的のファイルが存在するディレクトリが深い場合はそこそこ時間がかかります。そこでよく使うコマンドはfzfを使って曖昧検索で対象を見つけて実行できるようにします。今回は個人的によく使うgitの変更ログをみるコマンドを作成しました。fi}このコマンドを実行するとカレントディレクトリ以下に存在するファイルがfzfにプレビュー付きで表示され、選択するとgitの変更履歴が表示されます。おわりにLSPが登場したことでIDE以外でもIDEの主要機能を使って開発することができるようになりました。IDEには主要機能以外にも様々な便利機能が存在しますが、それらはLSPの責務外なため存在しません。コマンドを組み合わせることで同等の機能を作ることはできます。この記事が快適なCLI環境の構築の手助けになれば幸いです。HelmHelmを使って公開されているChartをインストール方法はたくさん紹介されていますが、独自のChartを作成する方法が簡潔に紹介されている記事が無かったので紹介します。Helm自体の紹介やインストール方法などは省略します。exampleで必要となるファイル一式が作成されます。中身は以下のようになっています。filesこのようなファイルが作成されますが、使わないファイルが多いので以下のファイル以外を削除します。配下がテンプレートが配置されるディレクトリになります。}}これに変数が代入されてマニフェストファイルが生成されます。コマンドでマニフェストファイルを生成します。{}テンプレートの変数テンプレートに代入された変数がどこに定義されたものか紹介します。"変数名"と宣言されているものが読み込まれます.ChartChart.yaml`に書かれた値を読み込んでいます.Release生成時に引数として渡されたものが読み込まれますその他の変数や関数はなんとなく雰囲気で理解できそうですが、以下の公式ドキュメントに書かれています。helm.shhelm.shhelm.shインストール生成したマニフェストファイルをパイプでkubectlに渡せばOKです。-また、helmが無い環境でもインストールするためにyamlファイルとして保存してしまうのも1つのやり方だと思います。manager以上の権限にすることで解決します。developerだとこのエラーになります。備考2FAの対応でアップロード用のアカウントを作ったときにこの問題に遭遇することが多いようです。以下のissueでdeveloper権限でこの問題を回避する方法が望まれていますが、まだ回避策は無いようです。Buffersでシリアライズ化することで高速な通信を実現させています。APIのデバッグでつかうcurlやPostmanのようなGUIツールでデバッグすることができません。そこで今回はgRPCで開発するときに役に立つデバッグの方法を紹介します。CLIクライアント一番基本となるデバッグ方法は自由にリクエストを送ることだと思います。以下のようにいくつかCLIからgRPCのリクエストを送ることができるツールがあります。grpc_cli公式が提供しているCLIクライアントgrpcurlcurl-likeなCLIクライアントgrpccREPLなCLIクライアント公式が提供しているツールを使うのもいいですが、curl-likeなほうが使い慣れた人が多いと思うのでgrpcurlがオススメです。このようにしてリクエストを送ることができます。Protocolというものがあります。通常は上記の例のように、リクエストを送ってレスポンスを表示するには関連する.protoファイルを指定する必要があります。Protocolを使えばサーバーから必要な情報を取得することができ、.protoファイルが無くても実行することができます。この機能を使うにはサーバーにReflectionの設定をする必要がありますが、数行に追加で済みます。Reflectionの対応は完了です。Reflectionに対応することで以下のようにサーバーに実装されているサービスの一覧や詳細も.protoファイルなしで確認できるようになります。サービスの一覧の表示は途中から開発に参加したプロジェクトなどではとても役に立つと思います。);環境変数サーバー側のデバッグ情報として環境変数を設定することで追加のデバッグ情報を出力することができます。これは各言語の実装により指定する項目が変わるので注意する必要があります。GoGoでは以下のように環境変数を設定すれば追加のログが出力されます。GRPC_GO_LOG_SEVERITY_LEVEL=infoドキュメントにも少しだけ記述があります。godoc.orgまた、Goの場合はGo自体に実装されたhttp2のデバッグ機能を使うのもオススメです。こちらはフレームの内容なども出力されるため、とても役に立つと思います。C#)の実装では以下のような環境変数を設定することで追加のログが出力できます。GRPC_TRACE=allCベースの場合は他にも設定できる項目があり、以下のドキュメントに書かれています。github.comまた、これらの環境変数はgRPCを内部で使用しているSDKなどでも有効です。GoogleのSDKではgRPCがたくさん使われているため、それらのデバッグでも有効活用できると思います。ReflectionTweet広告を非表示にするコメントを書くもっと読む2019-07-27Digdagのbackfillを無効化するDigdagDigdagでスケジュール実行の設定をしているワークフローを一時停止したあとに停止を解除した場合は、停止していた期間に実行されるはずだったセッションを実行するBackfillという機能があります。GUIでPAUSEした後にRESUMEしたときや、CLIでのenable/disableを実行したときが該当します。この機能はデフォルトで有効になっているため、冪等性が保たれていないジョブなどを一時停止した場合はBackfillを無効にする必要があります。rescheduleを実行する方法とマニフェストファイルでskip_delayed_byを設定する方法があります。rescheduleコマンドを使う方法rescheduleコマンドでスケジュールを更新して現時刻よりも前にスケジューリングされたセッションをスキップするように設定します。Backfillを無効にしたいワークフローのIDを取得します。CLIからは以下のコマンドで取得できます。schedules取得したIDで以下のコマンドを実行すればBackfillを無効にできます。%z')"このやり方で注意しなければいけないポイントとして、Backfillが無効になるのは今回の一時停止で実行されなかったセッションだけであるところです。後日また一時停止したときにもBackfillを無効にする場合は再度rescheduleコマンドを実行する必要があります。冪等性が無い場合など、毎回Backfillを無効にしたい場合は2つめのやり方で設定できます。skip_delayed_byを設定する方法マニフェストファイルのscheduleにskip_delayed_byを設定することで、指定された期間よりも以前のセッションをスキップするように設定できます。例としては以下のようになります。...この例の場合は一時停止を解除した時刻の3mよりも前のセッションを無効にします。この設定を1sとかにしておけばBackfillを完全に無効にできます。ワークフローの内容によりBackfillが実行されると不都合がある場合は、この設定を入れておくことをオススメします。Modulesに対応させたプロジェクトをDocker内でビルドして実行するとします。単純にDockerfileを書いてしまうとソースコードに変更が入るたびにModulesのダウンロードが走ってしまい、とても時間がかかってしまいます。そこでDockerのイメージレイヤのキャッシュ機能を使って高速化する方法を紹介します。コマンド部分が、前回の状態と異なるためキャッシュを使うことができないところにあります。そのため、ソースコードをコピーする前にModulesのダウンロードを行えば、ソースコードの変更を行っても前回のキャッシュが使え、大幅な短縮になります。実行してダウンロードしています。実行されるため、大幅な短縮になります。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。