Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法

Kasai Kou
January 21, 2023

Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法

Kasai Kou

January 21, 2023
Tweet

More Decks by Kasai Kou

Other Decks in Technology

Transcript

  1. 目次(TL;DR) • 自己紹介 • Dev Containers とは ◦ なぜ開発環境にコンテナの 恩恵がほしいのか

    • 開発環境と実行環境の違い • コンテナを作成する際の基本方針 ◦ あらゆるキャッシュをどんどん活用する ◦ コンテナのベストプラクティスは ある程度使える 3 • 失敗から学ぶ開発環境運用法(前編) ◦ rootユーザを使うな ◦ WSL2を使おう • 失敗から学ぶ開発環境運用法(後編) ◦ 過剰な固定を避ける ◦ パッケージはイメージに入れない ◦ RUN コマンドを無理にまとめないのが吉
  2. 自己紹介 • ボカロP / プログラマみならい ◦ Golang / Terraform が多め

    ◦ 個人的には技術記事書く方が好き • 2022年はインターンばかりの1年でした... ◦ 全部AWS or GCP絡みの長期インターン • 千葉工業大学 機械電子創成工学科 B3 ◦ 情報工学が主軸の学科ではないです(念の為) • 24卒ゆめみ入社(予定) 5 原神の好きなキャラは放浪者です...! Twitter: streamwest1629 Github: streamwest-1629 好きなゲーム: 原神 (‘23年1月現在) Twitterフォローしろ~ いいねくれ~ Profile illustrated by もこね, Gopher: ©tottie / Renée French
  3. 今回のスライドについて(露骨な宣伝) • VSCode Advent Calendarで書いた Zennの記事 • 本日の発表内容のベースの話 ◦ この記事を基にスライドを作りました

    • このスライド自体も公開 ◦ これで発表時間が足りなくなっても安心🤗 6 原神の放浪者とは関係ないよ(たぶん) VSCode Devcontainer 放浪記
  4. Dev Containersとは (TL;DR) テーマ: 開発環境もコンテナで! 10 コンテナは2020年入ってから初めて知りました Image: https://code.visualstudio.com/docs/devcontainers/containers •

    開発環境をコンテナイメージとして管理 ◦ コンテナとして管理するといいことが多い • コンテナ内に入って開発を行う ◦ ソースコードをバインドマウントさせる
  5. (一般的に)なぜコンテナを使いたいのか • コンテナ以外に依存関係がない ◦ コンテナイメージだけで全機能が完結している ◦ コンテナの実行環境によって「あのライブラリがない」 「あのバージョンがない」がなくなる • 移植性が高い

    ◦ 一度記述すればどこでも何台でも実行できる ◦ ローカルテストも本番環境での実行も同一の動作が期待できる 13 コンテナじゃないとどんな依存関係があるのかわからなくて不安になりますね...
  6. (個人的に)なぜコンテナを使いたいのか • 環境の構築方法がすべて記述される ◦ Dockerfileに構築方法を記述するため, 「どうやって環境構築するんだっけ?」がなくなる • ファイル管理がしやすい ◦ 基本的にはソースコードと同一の方法で

    管理・編集ができる ◦ Dockerfileはソースコードと同様に,Gitなどの 管理下に置くことで一緒にバージョン管理ができる • プロジェクトごとに最適な環境を用意できる 14 Linux,コンテナから入りました
  7. Dev Containerを使う前に何があったのか • マシンを新調・初期化する際に同一の環境構築ができなかった ◦ そもそも何を入れていたのか覚えていない ◦ どうやってインストールしたのか覚えていない ◦ バージョン違いをインストールしてしまった

    ◦ 同一のものを入れても期待していた動作と違う ▪ 依存関係が異なっているなど • プロジェクトごとに期待している開発環境が違う ◦ そのプロジェクトに必要な自作ツールがあったりする ◦ プロジェクトごとに使用しているバージョンやライブラリが違う ◦ VSCode拡張機能が衝突して想定外の動作をする 16 Dev Container導入前は色々なゴタゴタがありました
  8. 実行環境と開発環境の違い 18 OS/ランタイム/ 共有ライブラリ等 コンパイラ・ ビルドツール等 デバッガ・ CLIツール等 開発支援ツール等 Image:

    https://containers.dev/overview 同じコンテナでも実行環境と開発環境が一緒なわけないよねという話
  9. イメージ外からマウントするタイプのキャッシュ • 別にパッケージやライブラリを管理・バージョン固定する仕 組みがあればそれに越したことはない ◦ pipやnpm, go modulesなど • 大事なのは単にコンテナで依存関係の固定ではなく、

    仕組み自体と動作可能な環境があることを保証し、 仕組みに応じた最適な環境を提供すること 26 「それをキャッシュとは呼ばんだろ」というツッコミはなしでお願いします コンテナだけでライブラリを固定する必要はない
  10. Dockerのベストプラクティスはある程度有効 • キャッシュを活かす事が最優先 • 一方でレイヤーは少ないに越した ことはない • 並行して行えるなら 並行していきたい 27

    キャッシュを活かしつつ、ベストプラクティスを模索する base publish downloader/builder 並行して作業できるならそれに越したことはないけれど無理せず
  11. Dockerのベストプラクティスはある程度有効 28 base publish downloader/builder ①apt-getなどを 中心に並行して進める ②レイヤーキャッシュを 活かしながら必要なツールを ビルドしたりダウンロードする

    ③必要に応じて ステージ数は調整する ④ビルドしたバイナリ・ ライブラリをCOPYする ⓪最低限必要な共通の ツールを入れる キャッシュも大事だし並行して行えるので一石二鳥
  12. 過剰な固定を避ける • 別にパッケージやライブラリを管理・バージョン固定する仕 組みがあればそれに越したことはない ◦ venvやnpm, go moduleなど • 大事なのは単にコンテナで依存関係の固定ではなく、

    仕組み自体と動作可能な環境があることを保証し、 仕組みに応じた最適な環境を提供すること 40 大事なことなのでもう一度 コンテナだけでライブラリを固定する必要はない
  13. イメージに入れたくないけど存在を担保する方法 わかりやすいのは大事 • 「npm ci」「pip install -r requirements.lock」などをコンテナ実行毎に呼び出せ ばいい •

    venvやnode_modulesを使ったり,ボリュームで永続化させたりすることで実行時間 を縮める事が可能 ◦ ボリュームの場合はディレクトリ(ファイル)の所有者の変更が必要 • Dev Containersにはコンテナ実行毎に任意のコマンドを実行するオプションがある (postStartCommandなど) コンテナ立ち上げ時に呼び出すしかない 過剰な固定を避けることで毎回実行する代わりに,イメージ を小さくすることができてキャッシュを柔軟に設定しやすい
  14. RUNコマンドは無理にまとめないのが吉 Dockerfileからbuild vs イメージをpull はどちらも一長一短な印象 • Dockerfileからビルドしていく場合は特に レイヤーキャッシュを活かしていきたい • コンテナレジストリからイメージをpullする場合は悩ましいが

    悩む前に一度,マルチステージビルドで解決するかどうかを検証 レイヤーは少ない方がいいが キャッシュを活かせる方も大事 無理に分けるのではなく,機能ごとにレイヤーを分けるのが肝要
  15. まとめ • コンテナを作成する際の基本方針 ◦ あらゆるキャッシュをどんどん活用する ◦ コンテナのベストプラクティスは ある程度使える 48 •

    失敗から学ぶ開発環境運用法(前編) ◦ rootユーザを使うな ◦ WSL2を使おう • 失敗から学ぶ開発環境運用法(後編) ◦ 過剰な固定を避ける ◦ パッケージはイメージに入れない ◦ RUN コマンドを無理にまとめないのが吉