https://zenn.dev/hinoshiba/articles/workstation-on-docker

こんにちは、CLI生活至上主義？の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。

さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。

この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、LinuxとmacOSのユーザフォルダPATHの違いを気をつけた点、docker outside of dockerを扱えるようにした点などがあります。

これまでの環境

過去に記事でも紹介したことがありますが、私の作業環境は以下のような構成となっておりました。

(画像の接続元は、iPadProとなっておりますが、他にもmacOSやWindowsなどをコンソールとして用いていたイメージです。)

基本的にCLIな作業は全てworkstation上のプロセスとして動作させ、それらをいじるためのscreenセッションを1つ起動しておき、各クライアントによるsshからscreenにattachする生活をしておりました。 正直いいますと、私の用途では、macOSやWindowsが手元にある状況では、あえてLinuxへattachする必要性は、ありません。 しかし、環境差異がどうしても気になり、このような構成を取っておりました。 具体例をあげると、

• 同じようなCLIツールを入れるにしても、パッケージマネージャ(brew, aptなど) の違いがある
• アーキテクチャ、OSの違いにより、依存物等が違う/そもそもインストールできない
• デフォルトのshellが違う(zsh, bash, ...)
• コマンドのデフォルト引数や、挙動が微妙に違う

などです。

設定の変更でどうにかなる点もありますが、そもそも設定を頑張る事自体が苦でした。 であれば、最初から一つの環境に集中し、そこを異なる環境から扱うようにしようと考えたわけです。

これまでの環境における課題

1つの環境に集中したとしても、管理するものは少なからずありました。.gitconfigのような設定ファイル(dotfile)群です。

みなさんは、どのように管理されていますかね。

私は、/home/<myuser> 配下をgit化し、remote repositoryに上げて、バックアップ兼構成管理としていました。 しかし、この方法、インストールしているソフトウェアのバージョンは一緒に管理されていません。 そのため、ソフトウェアの入れ直しや、作業環境環境の引っ越しなどで、そのまま動作しないといったストレスを抱えておりました。 作業環境DRにて扱うケースや、職場で私用の.vimrcを参照したいケースでもうまく行かないケース も稀にあり、その度に環境毎で分岐しそうになる自身のdotfileに頭を悩ませていました。