


「このMacについて」→「ストレージ（タブ）」→「管理」から空き容量を作ることができますが、システムデータという編集が不可能な項目で300GB近く専有しており、削除までに調査が必要だった話

## 正体は~/Library/Containers/com.docker.docker

ググると貴重な情報が得られた

> The "System" category appears to be including sandboxed application data, which is stored in ~/Library/Containers/.
I used About This Mac | Storage | Review Files | File Browser to navigate to the folders/files using the most space and found that Docker was growing a file called Docker.qcow2 indefinitely in ~/Library/Containers/. Deleting the file released 30GB from "System" while "Documents" stayed the same size.

`du`コマンドで掘り進めていくと`~/Library/Containers/com.docker.docker`が200GB近くとっていた

## docker system pruneで半分解決

いつも`docker system prune`して数GB単位で減っていたので、dockerを疑ってなかったので驚いた

ドキュメントを見てみると、なんとvolumeはデフォルトでは削除されない模様。ずっと勘違いしていた

volumeも含めるオプションをつけて78GBの削除に成功、、いや残りの約120GBは？

```bash
docker system prune --all --force --volumes
```

## Docker.rawという１つのファイルに全部残ってた

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

なぜかResourcesのAdvancedタブが消えていて（Proxyしかない）、サイズをいじれなかった。

Clean/Purge Dataを実行して、一旦十分な容量を確保できたのでここで打ち切る

## References

- https://support.apple.com/ja-jp/HT206996
- https://qiita.com/ktsujichan/items/726e0f896e30b355fee1
- https://docs.docker.com/engine/reference/commandline/system_prune/

「このMacについて」→「ストレージ（タブ）」→「管理」から空き容量を作ることができますが、システムデータという編集が不可能な項目で300GB近く専有しており、削除までに調査が必要だった話
<h2 id="正体はlibrarycontainerscomdockerdocker">正体は~/Library/Containers/com.docker.docker</h2>
ググると貴重な情報が得られた
<blockquote>
The &quot;System&quot; category appears to be including sandboxed application data, which is stored in ~/Library/Containers/.
I used About This Mac | Storage | Review Files | File Browser to navigate to the folders/files using the most space and found that Docker was growing a file called Docker.qcow2 indefinitely in ~/Library/Containers/. Deleting the file released 30GB from &quot;System&quot; while &quot;Documents&quot; stayed the same size.
</blockquote>
<code>du</code>コマンドで掘り進めていくと<code>~/Library/Containers/com.docker.docker</code>が200GB近くとっていた
<h2 id="docker-system-pruneで半分解決">docker system pruneで半分解決</h2>
いつも<code>docker system prune</code>して数GB単位で減っていたので、dockerを疑ってなかったので驚いた
ドキュメントを見てみると、なんとvolumeはデフォルトでは削除されない模様。ずっと勘違いしていた
volumeも含めるオプションをつけて78GBの削除に成功、、いや残りの約120GBは？
<pre><code class="hljs language-bash">docker system prune --all --force --volumes
</code></pre>
<h2 id="dockerrawという１つのファイルに全部残ってた">Docker.rawという１つのファイルに全部残ってた</h2>
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
なぜかResourcesのAdvancedタブが消えていて（Proxyしかない）、サイズをいじれなかった。
Clean/Purge Dataを実行して、一旦十分な容量を確保できたのでここで打ち切る
<h2 id="references">References</h2>
<ul>
<li><a href="https://support.apple.com/ja-jp/HT206996">https://support.apple.com/ja-jp/HT206996</a></li>
<li><a href="https://qiita.com/ktsujichan/items/726e0f896e30b355fee1">https://qiita.com/ktsujichan/items/726e0f896e30b355fee1</a></li>
<li><a href="https://docs.docker.com/engine/reference/commandline/system_prune/">https://docs.docker.com/engine/reference/commandline/system_prune/</a></li>
</ul>

300GBあった「システムデータ」を削除した話




Next.jsとRuby on RailsのプロジェクトをDockerを通じて環境依存せず指定した言語バージョンで構築する

## アーキテクチャの指定

ローカルがM1 Macでデプロイ先が非armの時などケースバイケースで

```bash
export DOCKER_DEFAULT_PLATFORM=linux/amd64
```

## Ruby on Rails

```bash
docker run --rm -v $(pwd):/app -w /app ruby:3.1.1 bash -c "gem install rails && rails new my-backend-website"
```

## Next.js

```bash
docker run --rm -v $(pwd):/app -w /app node:17.8.0 npx create-next-app --example blog-starter-typescript my-frontend-website
```


Next.jsとRuby on RailsのプロジェクトをDockerを通じて環境依存せず指定した言語バージョンで構築する
<h2 id="アーキテクチャの指定">アーキテクチャの指定</h2>
ローカルがM1 Macでデプロイ先が非armの時などケースバイケースで
<pre><code class="hljs language-bash">export DOCKER_DEFAULT_PLATFORM=linux/amd64
</code></pre>
<h2 id="ruby-on-rails">Ruby on Rails</h2>
<pre><code class="hljs language-bash">docker run --rm -v $(pwd):/app -w /app ruby:3.1.1 bash -c &quot;gem install rails &amp;&amp; rails new my-backend-website&quot;
</code></pre>
<h2 id="nextjs">Next.js</h2>
<pre><code class="hljs language-bash">docker run --rm -v $(pwd):/app -w /app node:17.8.0 npx create-next-app --example blog-starter-typescript my-frontend-website
</code></pre>

WEBフレームワークをDockerで作るワンライナー

Nextとしてサーバーを建てるのではなく、RailsのViewからscriptタグでJS配信するだけなら、本番イメージ内にインストールする必要ないのでは？と思ったらできた話

## 1. Dockerfileからnodeを取り除く

よくある下記のようなDockerfileではこれだけで数百MBイメージサイズが増える。これを外す

```Dockerfile
RUN apt-get install -y nodejs npm && \
 npm install -g yarn

COPY package.json yarn.lock ./
RUN yarn install
```

## 2. assets:precomplieはCircleCIでやる

こんな感じでorbsをフル活用するとスムーズにDockerfile外でビルドできた。rubyもnodeもキャッシュをよしなにしてくれるのでとても高速

```yml
version: "2.1"

orbs:
 ruby: circleci/ruby@1.4.0
 node: circleci/node@5.0.0

jobs:
 check:
 docker:
 - image: cimg/ruby:3.1-node
 steps:
 - checkout
 - ruby/install-deps
 - node/install-packages:
 check-cache: detect
 pkg-manager: yarn
 - run: bin/rails assets:precompile
```

## 3. manifestをイメージに追加する

S3からの配信を予定しているが、マニフェストファイルだけはイメージに取り込まないと`javascript_pack_tag`などが正常に動作しなかった。

webpackerのものは`public/packs/manifest.json`と固定値だが、アセットパイプライン本体のものは`public/assets/.sprockets-manifest-<< hash >>.json`といった動的なパスになる。

Dockerfileでは`COPY . .`して全追加する際にマニフェストだけは追加しつつJS、CSSは除外するように`.dockerignore`を調整した。

```bash
/public/assets
!public/assets/.sprockets-manifest-*.json
/public/packs
!public/packs/manifest*
```

なおCI上でこのままAWS CLIを使ってS3に丸ごとアップロードすれば、Rails内に`asset_sync`, `fog-aws`を追加する必要もない。

最後にCDN配信なので、asset_syncを使わない場合は`config.asset_host = ENV['CDN_HOST']`といった具合にホストを指定して無事に配信ができた。

Nextとしてサーバーを建てるのではなく、RailsのViewからscriptタグでJS配信するだけなら、本番イメージ内にインストールする必要ないのでは？と思ったらできた話
<h2 id="1-dockerfileからnodeを取り除く">1. Dockerfileからnodeを取り除く</h2>
よくある下記のようなDockerfileではこれだけで数百MBイメージサイズが増える。これを外す
<pre><code class="hljs language-Dockerfile">RUN apt-get install -y nodejs npm &amp;&amp; \
 npm install -g yarn

COPY package.json yarn.lock ./
RUN yarn install
</code></pre>
<h2 id="2-assetsprecomplieはcircleciでやる">2. assets:precomplieはCircleCIでやる</h2>
こんな感じでorbsをフル活用するとスムーズにDockerfile外でビルドできた。rubyもnodeもキャッシュをよしなにしてくれるのでとても高速
<pre><code class="hljs language-yml">version: &quot;2.1&quot;

orbs:
 ruby: circleci/ruby@1.4.0
 node: circleci/node@5.0.0

jobs:
 check:
 docker:
 - image: cimg/ruby:3.1-node
 steps:
 - checkout
 - ruby/install-deps
 - node/install-packages:
 check-cache: detect
 pkg-manager: yarn
 - run: bin/rails assets:precompile
</code></pre>
<h2 id="3-manifestをイメージに追加する">3. manifestをイメージに追加する</h2>
S3からの配信を予定しているが、マニフェストファイルだけはイメージに取り込まないと<code>javascript_pack_tag</code>などが正常に動作しなかった。
webpackerのものは<code>public/packs/manifest.json</code>と固定値だが、アセットパイプライン本体のものは<code>public/assets/.sprockets-manifest-&lt;&lt; hash &gt;&gt;.json</code>といった動的なパスになる。
Dockerfileでは<code>COPY . .</code>して全追加する際にマニフェストだけは追加しつつJS、CSSは除外するように<code>.dockerignore</code>を調整した。
<pre><code class="hljs language-bash">/public/assets
!public/assets/.sprockets-manifest-*.json
/public/packs
!public/packs/manifest*
</code></pre>
なおCI上でこのままAWS CLIを使ってS3に丸ごとアップロードすれば、Rails内に<code>asset_sync</code>, <code>fog-aws</code>を追加する必要もない。
最後にCDN配信なので、asset_syncを使わない場合は<code>config.asset_host = ENV[&#39;CDN_HOST&#39;]</code>といった具合にホストを指定して無事に配信ができた。

UMIHICO BLOG.

#Docker

300GBあった「システムデータ」を削除した話

WEBフレームワークをDockerで作るワンライナー

React on Railsで本番イメージをNodeレスにした