けけずんセルフハッキング

エンジニアっぽい雰囲気を醸しだしているかのようなブログです!

2023年振り返り

はじめに

2023年の振り返りをする。

ちなみに最後に書いた振り返りが2019年の振り返り。

2020年以降が振り返れてなかったので、まずは大まかに2020年から2022年を振り返っていく。

2020年〜2022年の大まかな振り返り

すごくうろ覚え。過去ツイやSlackの書き込み見ながら思い出した。

2020年

  • 2019年末から続けていた案件が4月ごろに終了
    • この間に関わってくれた方々には本当にお世話になった
  • 週末土日は大体はオフィスででじぴよ活動してた
  • でじぴよ初のpublicイベントを開催
    • 今後も続けていこうと思いきや、コロナウィルスによりイベントが開催できず
    • 当時集まってくれた方々に感謝
  • コロナウィルス禍は身内だけでもくもく会を開催してた
    • ここから29回も続けてたのすごい。集まってくれた仲間たちに感謝
  • 実家住みだったが引っ越して一人暮らしを始めた
    • 1Kの狭い部屋で自炊しながらの生活は悪くなかった
    • しばらくして1Kの狭い部屋で同居生活が始まったが、それもそれで悪くなかった
  • 10月以降の仕事が激務で大変だった
    • ここから翌年4月まで激務が続いた

2021年

  • 2020年末からの激務が4月まで続き大変だった
    • 開発メンバー皆で乗り切った。大変さもあるが、皆で一丸になって頑張ることは楽しかった
  • 仕事で開発はほどほどに行い、EMの仕事を多めにこなすようになった
    • 人事制度など何やっていいかわからない中、色々と模索しながら動いてた
  • お家が狭かったので1LDKのお部屋に引っ越した
    • 新築はキレイで最高なりね
  • 10月頃に首をやらかし、2ヶ月ほど仕事を休ませてもらった
    • 代表のカンボさんと他のメンバーに迷惑をかけてしまったが、このとき休ませてくれて本当に助かった
    • 文字通り、ご飯とお風呂とトイレ以外はベッドで横になる生活をしていた
      • あまりにも暇すぎてラノベやソシャゲに手を出した。ラノベ無職転生を読み切った。ソシャゲは原神やってみたけど続かなかった
  • 首を痛めてからでじぴよ活動は休止した
    • でじぴよメンのみんなすまんな!

2022年

  • ほぼほぼ活動自粛期間。様々なイベントへの出席を控えて首を治すことに注力した
    • 年の後半は徐々にイベントに出席してたようであった
  • 仕事は時短勤務で復帰しつつ、休み休み作業をしていた
    • PMや開発メンバーのみんなが調整してくれたおかげで本当に助かった
  • モンハンサンブレイクが発売されたので時間が溶けた
  • 自家用車のプリウスちゃんがボロボロになってきたので、3年落ちの車を購入した
    • ガソリン車で燃費がよろしくないのでお金が飛んでいく。次買うならハイブリッドにする絶対にだ
  • 年末に親友が彼女も一緒に沖縄に来ていたので一緒に琉球村に遊びに行った
    • 本来30分程度で終わる焼き物体験を2時間ほどかけて行ったの最高に面白かった

2023年の月毎の振り返り

ここから本題の2023年の振り返り。

1月

年始からはあすけん始めて、ベースブレッドを定期購入するようになっていた。体系が気になり始めていたので、このあたりから栄養バランスを意識するようになっていたらしい。

月末には年末に手掛けた焼き物が焼かれて送られてきた。思ったよりもいい出来だった。

2月

首の調子が少しずつ良くなってきたらしく、でじぴよ活動(多分もくもく会)を再開していた。

あとポストはしていなかったが、D#さんが開催したビーパに参加し、その翌週にでじぴよでビーパを開催したりした。そのときに仕事の案件で仲良くなった方が本土から沖縄に来て参加してくれたので、でじぴよメン皆で喜んでいた。

3月

でじぴよでデザイナとエンジニアでハッカソンをしていた。丸1日使って皆で集まってたけど、段取りがよくなかったのもあって消化不良で終わってしまった。反省を活かして次回また開催したい。

この時期は割と本を読んでいたらしい。読んだ内容を概要だけでもいいので記録しておけばよかったな〜〜。

あと月末はディズニーランドに遊びに行ったりもしていた。首が痛かったので飛行機が辛すぎた。

4月

コロナウィルスに感染して一週間ほど横になっていた。眠っても全然時間が進まず、咳と頭痛と怠さに苦しめられていた。咳すると首が痛くなるのでだいぶしんどかった記憶がある。

これまでは仕事でバックエンドはLaravel、フロントエンドはNext.jsという案件に関わることが多かったが、今回から初めてバックエンドがNode.jsという案件に携わった。

5月

GW中に無事にコロナから復帰していた。もう二度とかかりたくないですな。

ティアキンやってたのこのあたりらしい。マップが広大過ぎてマップ埋めるの大変だった。

6月

弊社人事のちひろさんが僕のインタビュー記事を書いてくれた。ちひろさんは人の良いところを見つけるのが得意で、それを言葉に出してくれる。嬉しいね。

このあたりから美容皮膚科に通って脱毛を始めていた。社内では脱毛エンジニアというわけわからん名前をつけられた。

7月

誕生日の月、また歳を重ねた。相変わらず首は治っていないが、徐々に痛みが和らいでいる感覚はあった。

20日には無事に入籍、皆から温かい言葉を頂いた。なお結婚式をするかしないかは未だに検討中である。

8月

割と強い台風が来ていた。これまで那覇が停電することはあまりなかったが、今回の台風では停電していた。那覇は短い時間で復帰していてが、他の地区は数日復帰しなかったところもあったらしい。

超絶久しぶりにLaravel Meetupに参加していた。やはりオフラインイベントは楽しい。

あとは人生初のアーマード・コアをプレイしているようであった。グランツーリスモのように細かくチューニングする必要があるのかなと思っていたが、プレイしてみると思っていたよりもシンプルにカスタマイズするゲームだったのでとっつきやすかった。

9月

色々と本を読み始めていた。ルールズ・オブ・プログラミングに関しては口語が読みづらいなと思い途中で諦めた。

以前から投資信託は活用していたが、不安な点もあったのでマネイロで投資について相談などしていた。相談から契約までのフローで良いユーザ体験ができたので良かった。

10月

何故かゼル伝ムジュラの仮面リメイクが無性にやりたくなったが、手元に3DSがなく、中古では定価より高い価格で販売されているものばかりだったので諦めていた。

でじぴよビーパを開催していたらしい。ポストしてなかったが、こちらも多くのメンバーが集まって楽しんでくれていたようで良かった。また来年も企画するぞ。

10年ほど前から施設に入院していた祖母が他界した。入院していたときから覚悟は決めていたが、それでもやはり悲しいものだった。育ててくれて本当にありがとう。

11月

新婚旅行で北海道に来た。僕らが訪れたときはまだ雪は降っておらず、気温も0度を下回っていなかったので比較的快適に過ごせた(沖縄よりはだいぶ寒かった)。ご飯が全部美味しくて、特にシマエナガクレープが印象に残ってる。クレープ美味しすぎて滞在中に3回も食べてしまったので皆にも食べてほしい。

読んだ本の内容を毎回忘れてしまうのでめぐてぃす(@20092014)の真似をしてastro-notion-blogを開設した。読んだ内容は記録していくぞ。

12月

スクラムフェス沖縄2023に参加してきた。エンジニア以外の色んな職種の方々とお話できて刺激になった。主催のいわむーさん(@takusamar)と運営の皆さんに感謝。

12月中旬には一人で京都から山口県まで、山陰本線に乗ってひたすら移動と宿泊を繰り返す旅をしていた。車窓から見える自然の景色を堪能しつつ読書をし、飽きたら宿泊先を探すなどをしていた。PCから離れ且つ一人で過ごす時間は新鮮だった。(山口県まで行った後、時間があったので佐賀県ニセコまで回ってきたよ)

2023年のまとめ

2023年はストレスになるようなことは極力避けるようにし、絶対に首を治すことを目標にしていた。実際は完治まではいかなかったが、合間に休憩を挟みながらであれば長時間PCを触っていても首が痛くならない程度にまでは治ってきた。 関わってくれた方々が支えてくれたおかげで、長い時間ながらもここまで回復することができた。本当にありがとう。

2024年の目標

  • 身体の調子を整える
    • 作業をする際は、1時間毎にストレッチする時間を確保する
    • 毎週運動する時間を取り入れる
      • 首の様子を見ながらバレーボール、ランニングを再開するようにしたい
  • 英語力上げる
    • リスニング、文法の勉強を継続する
  • 技術を習得する
    • 転職先で使用する技術スタックへの理解を深める
    • バックエンド、フロントエンドの設計・アーキテクチャの知見を得て、実務に活かす
    • プロダクトを成長させるマインドを持つ
  • イベントに参加する、開催する
    • でじぴよイベントを毎月開催する
    • エンジニアリング以外のイベントにも参加する

スクラムフェス沖縄2023 に参加してきた

はじめに

スクラムフェス沖縄が2022年に行われた(このときは第0回らしい)。 当時、別のイベントで主催者のいわむーさん(@takusamar)が参加者を募っていたので興味があったが、自分が他のイベントと被っており参加できないため見送っていた。

そのため一年越しになるが、今回のスクラムフェス沖縄2023に参加させていただいた。

https://www.scrumfestokinawa.org/

1日目

初日は平日夕方から開始。席周辺の方々と自己紹介を行った。 自己紹介の際、他の方々から質問を受けて解答するという記者会見方式で行っていたのが印象的だった。単純に楽しさもあったが、他者の自己紹介を一方的に聞くだけという状況よりも記憶に残りやすく、自己紹介を受けて気になったことなどをその場で質問できるため良いなと思った。自分が主催する他のイベントでもやってみたいところ。

自己紹介後は運営の方々が用意してくれたガーリックチキンを食べながら雑談タイム。ガーリックチキンは大好きなので食べたかったが、他の方々と話すのに夢中になってしまっていた。少しだけ心残りである。

2日目

二日目の午前はOSTとTDDワイワイ会が平行で行われた。自分は「トークテーマの考え方」というテーマでOSTに参加した。

下記は自分が話した内容。

  • トークテーマの考え方」というテーマにした理由
    • 自分自身イベントで登壇するとなったときにテーマを考えるのが難しいなと感じていたから
  • なぜテーマを考えるのが難しいと感じるのか
    • 「ドキュメントに記載されてることだからわざわざ話す必要ないよな」とか「自分が当たり前のようにやっていることに面白味はない」といった気持ちになり自信が持てないため

上記に対して参加者の方々から下記のような意見をいただいた。

  • 自分を一歩引いてみる
  • 100人全員に好かれなくてもいい
  • 自分のものさしでみない
  • 同じ事でも自分の気持ちをいれるといいね
  • 自分の当たり前を話してもいい
  • 好きな気持を発信
  • 他のイベントでも同じテーマで発表して、他の人たちの反応を見るのもいいかも

ざっと箇条書きしたが、実際は一つ一つの項目について参加者の方々と議論を交わしながら進めていた。これがとても面白かった。普段は他者に自分のことについて話すことがなかったが、OSTの場の中で自分が感じていたこと思っていたことを素直に話せたということが自分にとって新鮮だった。

OSTの後はTDDワイワイ会に参加しようと思っていたが、OSTがだいぶ面白かったので他の人が話している場に参加。結局TDDワイワイ会に参加することはできなかったが、OSTという初めての体験ができて良かった。

おわりに

これまで聴講するオフラインイベントには何度も参加してきたが、参加者の方々と対話するイベントは初めてな気がした。OST良いので別でイベント企画してまたやりたいな〜〜〜〜。

参考

https://speakerdeck.com/spring_aki/minna-de-kisyakaiken https://speakerdeck.com/shuyuhey/tddwaiwaihui https://www.slideshare.net/kdmsnr/legoscrumawakens20160119

Linuxカーネルのコンテナ機能について調べたことメモ

はじめに

Linuxカーネルのコンテナ機能について記述されている記事を読んでメモ書きを残す。

“RedHat Linuxコンテナについて理解する” を読んでのメモ

Linuxコンテナとは

https://www.redhat.com/ja/topics/containers/whats-a-linux-container

  • Linuxコンテナとは
    • システムの他の部分とは分離された一連のプロセス
    • アプリケーションとランタイム環境全体、つまり実行に必要なすべてのファイルをパッケージ化し、分離させるテクノロジー
    • コンテナ内のアプリケーションを、すべての機能を維持したまま複数の環境 (開発、テスト、本番環境など) の間で容易に移行することができる
    • Linuxカーネルに『コンテナ』という単一の機能が実装されてコンテナが実現しているわけではない
      • OSリソースの隔離 → Namespace(名前空間
      • ホストの物理リソースに対する制限 → cgroup(Control group)
      • ネットワーク → veth, macvlan
      • ケーパビリティ
      • chroot
      • bind mount
  • なぜコンテナを使うのか
    • 本番環境と同等の構成を再現するオーバーヘッドを短縮できる
    • イメージを共有することで、開発チーム全員が同様の環境でアプリケーションの開発ができる
    • 開発チームと運用チームの責任範囲を分離でき開発者はアプリケーションに集中でき、運用チームはインフラストラクチャに注力できる
  • コンテナと仮想化の違い
    • 仮想化では、複数のOS (Windows または Linux) を単一のシステム上で同時に実行できる
      • ハイパーバイザーを使用してハードウェアをエミュレート、複数のOSを並列で実行できる
    • コンテナでは、同じOSカーネルを共有し、アプリケーションプロセスをシステムの他の部分から独立させる
      • 単一のOSで実行され、同じシステムを共有するため軽量
  • コンテナの歴史
    • 2000年に登場したFreeBSD jailsが始まり
      • jailはシステム管理者が組織内外の複数のユーザーと共有できる安全な環境として開発された
    • 2001年には、Jacques Gélinas氏のVServerプロジェクトを通じて、Linux にも隔離環境の実装が登場
      • これが後のLinuxコンテナに発展する
    • cgroupはロセスまたはプロセスのグループによるリソース使用を制御および制限するカーネル機能
    • systemdはユーザー空間をセットアップしてプロセスを管理する初期化システム
    • 2008年にDockerが登場

Dockerとは

https://www.redhat.com/ja/topics/containers/what-is-docker

  • Dockerとは
    • Linuxコンテナの作成と使用を可能にするOSS
  • Dockerの仕組みと目的
    • Linuxカーネルとcgroupや名前空間などのカーネルの機能を採用し、プロセスを隔離してそれぞれ独立して実行することが可能
    • 複数のプロセスやアプリケーションを互いに分離して実行できることがコンテナの要点
  • Dockerでできること
    • アプリケーションやサービス群をそれぞれの依存関係と一緒に、複数の環境間で容易に共有できるようになる
    • コンテナ環境内におけるアプリケーション (または、アプリケーションを構成するプロセス群の組み合わせ) のデプロイも自動化できる
  • DockerとLinuxコンテナの違い
    • Dockerは元々LXC (Linux コンテナ) 技術をベースに構築されたものだが、これらは異なる技術である
      • LXC = 軽量な仮想化ツール、開発者やユーザにとっては使いにくかった
      • Docker = コンテナの作成とビルド、イメージの配布、バージョン管理のプロセスを容易にする

“LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術” を読んでのメモ

第1回 LXCとコンテナの基本

https://gihyo.jp/admin/serial/01/linux_containers/0001

  • LXCはLinuX Containerの略、異なる意味で使われることがある
    • 広義の意味 → ⁠Linuxカーネルが持つ機能を使って実現するコンテナ
    • 狭義の意味 → ⁠linuxcontainers.org で開発されているコンテナを扱うためのソフトウェア ← 本書ではこの意味で使っている
  • Linuxでコンテナを実現するためのソフトウェア
    • OpenVZ
      • Linuxカーネルにコンテナ関連の技術が充分に実装されていないかなり前から、Linuxカーネルにパッチを当ててコンテナを実現
      • 現在のLinuxカーネルに実装されているコンテナ関連の実装にはOpenVZ由来のものが多くある
      • 現在でもOpenVZの開発者が実装を進めている機能が存在する
    • libvirt
      • 仮想マシンの操作を行う共通のAPIを提供するライブラリ
      • 前述した広義の意味のLXCをサポートしている
    • Docker
      • Go言語で書かれたソフトウェア
      • 元々はコンテナを実現するためにLXCを使っていたが、最近のリリースである0.9で自身でコンテナを作成するライブラリを実装し、デフォルトではそちらを使うようになった
    • その他にもいろいろあるらしい
  • ubuntuにlxcコマンドをインストールしてコンテナ実行の操作を紹介してる

第2回 コンテナの仕組みとLinuxカーネルのコンテナ機能[1] 名前空間とは?

https://gihyo.jp/admin/serial/01/linux_containers/0002

  • コンテナの仕組み
    • VM
      • コンピュータの上で動くOSやVMを実現するためのハイパーバイザの上で、実際のハードウェアをエミュレートするVMが動く
      • VMを動かしているOSからはVMのプロセスが見えているだけで、VM上で動作しているプロセスは見えない
    • コンテナ
      • 起動する全てのプロセスはコンピュータ上にインストールされたOS(ホストOS)上で直接起動する
      • プロセスの一部をグループ化し、他のグループやグループに属していないプロセスから隔離した空間で動作させる ← この空間をコンテナと呼ぶ
        • ホストOS上で直接動作するプロセスや他のコンテナから独立した空間を作り出し、リソースを分割、分配、制限する
  • コンテナのメリット
    • 高密度化が可能
    • オーバーヘッドが少ない
    • 起動が速い
    • アプリケーションのみの起動が可能
      • アプリケーションコンテナと呼ぶ
      • 通常のOSが起動するのと同じような環境はシステムコンテナと呼ぶ
  • コンテナのデメリット
    • 異なるOSのシステム、プログラムは動かせない
    • カーネルに関わる操作はできない
  • 名前空間(Namespace)とは
    • プロセスをグループ化して、コンテナの隔離された空間を作り出す機能
    • 名前空間は『名前空間』という機能がひとつ存在するわけでなく、独立させたいリソースによっていくつかの機能がある
  • PID名前空間
    • プロセスIDを名前空間ごとに持つことができる
    • 通常はPIDは一意に決まる数字が振られますが、異なる名前空間にいるプロセスは同じPIDを持つことができる

第3回 Linuxカーネルのコンテナ機能[2] ─ cgroupとは?(その1)

https://gihyo.jp/admin/serial/01/linux_containers/0003

  • cgroupファイルシステム
    • cgroup機能を使ってプロセスをグループ化したものをcgroupと呼ぶ
    • cgroupファイルシステム(以降cgroupfs)という仮想的なファイルシステムを使って操作する
    • cgroupに登録したプロセスの子プロセスやその子孫も自動的に同じcgroupに登録される
    • cgroupに登録されているプロセスを別のcgroupに移動させたいときは、単に移動させたいcgroupにPIDを登録するだけ
    • cgroupfsをマウントすると、まずはシステム上の全てのプロセスがここに登録される
    • 階層構造のサポートがcgroupのもうひとつの特徴

第4回 Linuxカーネルのコンテナ機能[3] ─ cgroupとは?(その2)

https://gihyo.jp/admin/serial/01/linux_containers/0004

  • サブシステム
    • リソースによって『サブシステム』と呼ばれる独立した機能でリソースを扱う
    • サブシステムは『コントローラ』と呼ばれることもある
    • CPUやめもりなど数値で表されるアクセス制限、cgroupに対するアクセス権を設定する機能がある
  • cpuサブシステム、cpuacctサブシステム、cpusetサブシステム
    • CPUのスケジューリング、CPU時間の割当、タスク実行合計時間、メモリノードの割当など
  • devicesサブシステム
    • ホストOSから見えているデバイスへのコンテナに対するアクセス権を設定できる
    • アクセス権の設定はcgroup内のdevices.allow、devices.denyに設定する
      • 3つのフィールドからなるエントリを設定し、アクセス権を設定する
        • タイプ、デバイスノード番号、アクセス権
    • 設定した結果はdevices.listファイルで確認できる
  • freezerサブシステム
    • リソースを制御するのではなく、cgroupに属するタスクそのものの制御を行う
    • cgroup内のプロセスを一括で一時停止させたり、一括で再開させたりできる

第5回 Linuxカーネルのコンテナ機能[4] ─ cgroupとは?(その3)

https://gihyo.jp/admin/serial/01/linux_containers/0005

  • Memoryサブシステム
    • コンテナに対してメモリの制限を行いたい場合に使用する
    • cgroupに対して制限値を設定したり、cgroupのメモリ使用量の監視をしたりできる
  • OOM Killer
    • Linuxでシステムのメモリが足りなくなった時に発動し、cgroup内のプロセスが強制終了される
    • OOM Killerを無効にして、eventfdを通じて通知を受け取ることもできる
      • 3.10 カーネルからはcgroup内のプロセスのメモリの圧迫度合いに応じて同様にeventfdで通知が行える
  • net_clsサブシステム
    • cgroupに属するプロセスが発信するパケットに識別用の識別子を付け、そのIDを使ってトラフィック制御ができるようにするための仕組み
  • blkioサブシステム
    • cgroup内のタスクのブロックデバイスへのI/Oを制御したり、cgroup内のタスクがどれくらいブロックデバイスへのアクセスを行ったかの統計値を取得できる
    • バイスからの読み込みの制限値、デバイスへの書き込みの制限値、IO操作の回数、転送されたバイト数
    • blkioサブシステムはダイレクトI/Oのみを対象で、ページキャッシュを使ったBuffered I/Oの書き込みの制限ができない
      • blkioサブシステムとmemoryサブシステムが連携して動作できないため
  • net_prioサブシステム
    • 複数のcgroupの間のインターフェースごとに優先度を設定できる
      • 設定に記述した数字が大きい方が優先度が高くなる

第6回 Linuxカーネルのコンテナ機能[5] ─ ネットワーク

https://gihyo.jp/admin/serial/01/linux_containers/0006

  • コンテナとネットワーク名前空間
    • ネットワーク名前空間を作成し、ホスト上に存在するネットワークインターフェースを、作成したネットワーク名前空間に割り当てる
      • ホストや他のコンテナからは見えない、コンテナからだけ見えるネットワークインターフェースとなる
    • ネットワーク名前空間を作らなくてもコンテナは作れるが、upstartやsystemdといったソケットを使用するinitが使われることが多いため、ネットワーク名前空間をホストと分けておくのが普通
  • ホストのインターフェースの使用
    • コンテナ用にネットワーク名前空間を作成した場合でも、ホスト上で認識されている物理的なネットワークインターフェースをコンテナに割り当てて使用できる
    • 同一のホスト上でコンテナを多数起動する場合は,コンテナの数だけホスト上で使っていないインターフェースが必要になる
  • veth
    • 元々OpenVZ/Virtuozzoに実装されていた仮想的なネットワークインターフェース
    • ホスト上にブリッジを作るので、ブリッジ上でNATすることも、ホストと同じネットワークに属することも可能
  • macvlan
    • 既に存在するeth0のような物理的なインターフェースに,新たにMACアドレスを持つ仮想的なインターフェースを作る
      • 1つのインターフェースに複数のMACアドレスを割り当てられる機能

第16回 Linuxカーネルのコンテナ機能 [6] ─ ユーザ名前空間

https://gihyo.jp/admin/serial/01/linux_containers/0016

第18回 Linuxカーネルのコンテナ機能 [7] ─ overlayfs

https://gihyo.jp/admin/serial/01/linux_containers/0018

  • overlayfsとは
    • union filesystemの実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーが構成できる
      • Dockerコンテナイメージの差分管理にunion filesystemの実装であるaufsが用いられている
      • Dockerも1.4.0からoverlayfsに対応したらしい
    • 現在はoverrayという名前になっているらしい
  • overlayfsのマウント
    • 重ねあわせた上層であるディレクトリに変更が加えられていく
    • 元から上層と下層にファイルが存在する状態でマウントすると、マウントしない状態で作ったファイル,ディレクトリが全て見える
      • 同一ファイル名の場合は上層ディレクトリのファイルが見える
    • 上層および下層にあるファイルに変更を加えた場合、上層側に変更がかけられる
    • 下層側に存在するファイルやディレクトリを削除すると"(overlay-whiteout)"へのシンボリックリンクが作成され,拡張ファイル属性"trusted.overlay.whiteout"が"y"に設定される

おわりに

コンテナの仕組みがある程度分かった気になった。 今回は記事読んだだけで手は動かしていないので、別の機会に触ってみて理解深めたい。

次回はこれを読む。

PhpStormからDockerコンテナ内のPHPUnitを実行する

この記事について

株式会社Re:Buildアドベントカレンダー Advent Calendar 2020 の11日目の記事。

PhpStorm開いてる人に「今開いているテストファイルのこのテスト関数実行してみて」というと、大体の人がphpunitコマンドを叩いて全てのテストを実行していた。テストコードが増えてきた段階でこんなことをしてしまうと待ち時間が大変なことになるので、PhpStormから特定のテストを実行する方法(というか設定)を書き残しておく。

準備

PHPUnitのテストをDockerコンテナ内で行うためのサンプルを作ったのでこれをcloneし、composer installを実行する(composerがローカルに入っていない人は申し訳ないが頑張ってインストールしてね。)

$ git clone git@github.com:kkznch/20201212-phpunit-with-phpstorm.git
$ cd 20201212-phpunit-with-phpstorm
$ composer install

準備できたらPhpStormで上記のプロジェクトを開いてね。

設定手順

PHP CLI Interpreterの設定

PHPを実行する際にどの環境のものを使用するのか設定する。

  1. PhpStormのPreferencesを開く
  2. "Languages & Frameworks"->"PHP"を開き、"CLI Interpreter"の右端にある"..."をクリックする f:id:kkznch:20201212165412p:plain
  3. 左上にある "+" ボタンをクリックし、"From Docker, Vagrant, VM, WSL, Remote..." を選択する f:id:kkznch:20201212170010p:plain
  4. "Docker Compose"を選択し、"Configuration file(s)"にPhpStormで開いているプロジェクトのdocker-compose.ymlファイルへのパスを入力、"Service"に起動するコンテナ名(今回はphpという名前)を指定する f:id:kkznch:20201212170610p:plain

ここまで設定すると以下の画面が表示される。 画面真ん中にある"Lifecycle"は、PHP実行時に都度コンテナを起動するか、または既に起動しているコンテナを使用してPHPを実行するか、の二択。 php-fpmのように常時起動しているコンテナであれば後者の方を選択してもいいが、今回は単発起動で十分なので前者を選択しておく。 ここで"OK"ボタンを押してCLI Interpreterの設定は完了。 f:id:kkznch:20201212170841p:plain

PHPUnit実行時のCLI Interpreterの設定

PHPUnitを実行する際にどのCLI Interpreterを使用して実行するか設定する。

  1. PhpStormのPreferencesを開く
  2. "Languages & Frameworks"->"PHP"->"Test Frameworks"を開き、"+"ボタンをクリックし、"PHPUnit by Remote Interpreter"を選択する f:id:kkznch:20201212171811p:plain
  3. "Interpreter"に先程PHP CLI Interpreterで設定した設定(今回はphpという名前)を選択し、"OK"ボタンをクリックする f:id:kkznch:20201212171829p:plain
  4. "Path to script"にコンテナ内にあるautoloaderへのパス(今回は/root/vendor/autoload.php)を指定し、"OK"ボタンをクリックする f:id:kkznch:20201212172056p:plain

これでPHPUnitの実行設定が完了。

実行方法

PhpStormで実行したいテストが記述されたファイル(tests/SampleTest.php)を開くと、エディタの行番号表示欄の右側に謎の緑色が見えるはず。クラス定義をしている行の緑色をクリックし"Run 'SampleTest'"を選択するとクラス全体のテストが実行される。

また、関数定義をしている行の緑色をクリックし"Run 'testFirst'"を選択すると、testFirstというテスト関数だけが実行される。 f:id:kkznch:20201212173335p:plain

おわりに

phpunitコマンドでも特定のテストファイル、特定のテスト関数のみを実行することはできるが、PhpStormからぽちぽち実行できると楽だよね。

この記事書いた後に「phpstorm コンテナ phpunit」で検索すると似たような内容の記事がいっぱいでてきたので、書く前に調べておけばよかったと反省している。

参考

qiita.com qiita.com

Terraform使ってみる(2) 〜 設定に変数用いて外から値を注入してみる編

概要

前回に引き続き、今回もTerraform触ってみる。 今回は設定ファイルに変数を使用し、コマンド実行時に外から値を注入してみる。

前回の記事はこちら

Terraform使ってみる

Terraformで設定ファイルに変数を使用する

公式的なサイトはこちら。 HashCorp Learn - Define Input Variables

事前準備

前回同様、任意の場所フォルダを作成する。

$ mkdir terraform-example
$ cd terraform-example

以下の内容で設定ファイル main.tf を作成する。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 2.70"
    }
  }
}

provider "aws" {
  profile = "default"
  region = "ap-northeast-1"
}

resource "aws_instance"  "example" {
  ami = "ami-830c94e3"
  instance_type = "t2.micro"
}

準備おっけー。

変数定義ファイルの作成と参照

設定ファイル main.tf と同じ場所に、以下の内容で変数定義ファイル variables.tf を作成する。 ここで変数として定義しておくことで、 terraform apply コマンド実行時にオプションで変数に値を割り当てることができる。 変数の値を指定していない場合は variables.tf で定義した default 値が使用される。

variables "region" {
   default = "ap-northeast-1"
}

これで設定ファイル main.tf の中で変数の値を参照できるようになった。 設定ファイル main.tf を以下のように編集する。

provider "aws" {
  profile = "default"
-  region = "ap-northeast-1"
+  region = var.region
}

変数への値割当て

上述したように terraform apply コマンド実行時にオプションで変数に値を割り当てることができる。 以下では region という変数に ap-northeast-1 という値を割り当てている。

$ terraform apply -var 'region=ap-northeast-1'

また、変数への値の割当をファイルから行うこともできる。 以下の内容の terraform.tfvars というファイルを作成する。 terraform.tfvarsterraform apply コマンド実行時にデフォルトとして自動で読み込まれる。

region = "ap-northeast-1"

なお terraform.tfvars ではなく my-variables.tfvars といった任意の名前をつけたとき、 以下のように terraform apply コマンド実行時にオプションでファイルを指定することで、ファイルに記述された値を変数に割り当てることができる。

$ terraform apply -var-file 'my-variables.tfvars'

変数のタイプ

変数には List や Map を使用することができる。

List

こちらが変数の定義。

variable "cidrs" { default = [] }

こちらが値の割当て。

cidrs = [ "10.0.0.0/16", "10.1.0.0/16" ]

Map

こちらが変数の定義。

variable "amis" {
  type = "map"
  default = {
    "us-east-1" = "ami-b374d5a5"
    "us-west-2" = "ami-fc0b939c"
  }
}

こちらが値の割当て。

resource "aws_instance" "example" {
  ami = var.amis[var.region]
  instance_type = "t2.micro"
}

おわりに

Terraformの設定ファイルに変数を用いて、値を外部から注入してインフラを構築できるようにはなった。 ファイル内に値を直書きするのもいいけど、それだと再利用性低いので、可変な値は変数化して使いまわしできるようにしていくとよさそう。

Terraform使ってみる(1) 〜 インストールして動かしてみる編

概要

いつも簡単なインフラばかり構築してたからコード化する必要ないよねって思ってたけど、最近それすら億劫になっている。 というわけで今更だけどTerraformを使ってみるよ。

Terraformのインストール

公式サイト的なのはこちら。

HashCorp Learn - Install Terraform

ひとまずコマンド実行。

$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform

インストールされたか確認する。

$ terraform -help
Usage: terraform [-version] [-help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

...

ヘルプっぽいものが表示されたからおそくら大丈夫でしょう。

Terraformで最低限のAWSインフラ作る

公式サイト的なのの手順に従ってAWSでインフラ作っていこう。

HashCorp Learn - Build Infrastructure

事前準備

以下の手順を済ませておく。

設定ファイルの作成と初期化

作業用のフォルダを作成し、その下に移動する。

$ mkdir terraform-example
$ cd terraform-example

設定ファイルを以下の内容で作成する。 今回はEC2インスタンスを一台立ち上げるだけ。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 2.70"
    }
  }
}

provider "aws" {
  profile = "default"
  region = 'ap-northeast-1"
}

resource "aws_instance"  "example" {
  ami = "ami-830c94e3"
  instance_type = "t2.micro"
}

以下のコマンドでそれぞれコードの整形と設定の検証してくれる。

$ terraform fmt
$ terraform validate
Success! The configuration is valid.

初期化処理を実行する。

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 2.70"...
- Installing hashicorp/aws v2.70.0...
- Installed hashicorp/aws v2.70.0 (signed by HashiCorp)

terraform init を実行すると .terraform というフォルダが作成される。 terraform init は設定ファイルを作成した際や、gitなど既存の設定ファイルをcheckoutした際に実行すればよいらしい。

インフラの作成

以下のコマンドを実行するとAWS上にインフラが構築される。

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ここに作成されるリソースが一覧される
  + resource "aws_instance" "example" {
      + ami = "ami-830c94e3"
      + arn = (known after apply)
      ...略
    }

...略

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.  

ここでAWSのコンソールを見てみるとEC2インスタンスが作成されている、すごい。

Terraformその他コマンド

インフラの更新

更新は設定ファイルを書き換えた後、terraform apply を再度実行するだけ。 このときに差分が見れるので、差分を見ながら問題がなければ yes と入力して実行する。

インフラの詳細確認

以下のコマンドで作成したリソースの情報を表示できる。

$ terraform show

インフラの削除

以下のコマンドで作成したリソースの削除ができる。

$ terraform destroy

おわりに

Terraformの基本的な使い方だけ書いた。 設定ファルで変数を使用したり、モジュール化したりなど色々なことができるらしいので、次回はそれを触ってみたい。

VSCodeでAwesome Emacs Keymap使ってるときに検索バー内でカーソル移動したい

概要

VSCodeのキーマップ拡張「Awesome Emacs Keymap」を使っている際、ctrl+sまたは⌘Fで出した検索バー内でカーソルの移動ができないことに微妙に不便を感じていたので自分でVSCodeのkeybindings.jsonを触ってカーソル移動できるようにした。

ちなみに検索時にカーソル移動できないのはEmacsのデフォの挙動なので、キーマップ拡張が悪いとかいう話ではない。 キーマップ拡張自体はとても優れていると思う、心から感謝してる。

方法

まず「VSCodeでキーバインドを設定する。keybindings.jsonが無い時の対処法」通りに keybindings.json を開く。

次に以下のコードをコピーしてペタッと貼る。

[
    {
      "key":  "enter",
      "command": "editor.action.nextMatchFindAction",
      "when": "editorFocus && findWidgetVisible && !replaceInputFocussed"
    },
    {
      "key": "ctrl+a",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    },
    {
      "key": "ctrl+b",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    },
    {
      "key": "ctrl+e",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    },
    {
      "key": "ctrl+f",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    },
    {
      "key": "ctrl+n",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    },
    {
      "key": "ctrl+p",
      "command": "",
      "when": "editorFocus && findWidgetVisible && findInputFocussed",
    }
]

今回は自分がカーソル移動時によく使う ctrl+a, ctrl+b, ctrl+e, ctrl+f, ctrl+n, ctrl+p だけを設定した。 上記以外の高度なカーソル移動(ワード毎に移動とか)をご所望の際は同じように書けば動作するはず。

終わりに

あ〜〜〜〜〜〜ちょっとだけ楽になった。

今回の件でキーマップ拡張のコードとか読んだりしたけど、OSS作ってくれる人ってホント凄いね、感謝。

参考リンク