回答編集履歴
2
勘違いしてた箇所を削除
test
CHANGED
|
@@ -62,36 +62,6 @@
|
|
|
62
62
|
|
|
63
63
|
|
|
64
64
|
|
|
65
|
-
> Dockerfile
|
|
66
|
-
|
|
67
|
-
npm installコマンドはキャッシュが効くようにアプリコードより先に単体でコピーしています。
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
`npm install`コマンドの結果はpackage.jsonとpackage-lock.jsonの状態で一意に決まるべきなので、
|
|
72
|
-
|
|
73
|
-
コマンドの文字列のみで判断するDockerにキャッシュを作ってもらうのはナンセンスです。
|
|
74
|
-
|
|
75
|
-
ビルド時に`--no-cache`オプションは半ば必須になりますから、
|
|
76
|
-
|
|
77
|
-
上記の理由で「キャッシュが効くように先にコピー」というのが全くメリットとして機能していません。
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
ソースコードを含めてまるごと
|
|
82
|
-
|
|
83
|
-
DockerHubの有料プランなり、ローカルのDockerHubクローン鯖なりで預かってもらって、
|
|
84
|
-
|
|
85
|
-
本番環境ではpullして動かすだけというところがゴールでしょうか？
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
この方向性はDockerを扱う上で理想的ですが、
|
|
90
|
-
|
|
91
|
-
package.jsonを先にコピーするまでもなく、`.dockerignore`に`app/node_modules`みたいな事を書いておけばcopy時に勝手に弾かれるのでそれでやればいいじゃんと思います。
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
65
|
> ライブラリ更新のたびにホストとコンテナで二重に実行する必要があるのでできれば避けたいです。
|
|
96
66
|
|
|
97
67
|
|
1
構
test
CHANGED
|
@@ -1,14 +1,6 @@
|
|
|
1
1
|
もうこんな風にローカルは生のalpine使って、
|
|
2
2
|
|
|
3
3
|
DroneみたいなCIツールにDockerBuildさせるような構成にしたほうがいいです。
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
ローカルにVSCodeとNode.jsをインストールしている時点で
|
|
8
|
-
|
|
9
|
-
環境を汚さないとか言ってても理想と現実がもう相当剥離してるんですが？？？状態になってます。
|
|
10
|
-
|
|
11
|
-
なので、ローカルにnode_modulesを作るという運用は避けられないでしょう。
|
|
12
4
|
|
|
13
5
|
|
|
14
6
|
|
|
@@ -37,6 +29,36 @@
|
|
|
37
29
|
- .:/app
|
|
38
30
|
|
|
39
31
|
```
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
ローカルにVSCodeとNode.jsをインストールしている時点で
|
|
36
|
+
|
|
37
|
+
環境を汚さないとか言ってても理想と現実がもう相当剥離してるんですが？？？状態になってます。
|
|
38
|
+
|
|
39
|
+
なので、ローカルにnode_modulesを作るという運用は避けられないでしょう。
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
質問文の要件はみたせませんが、今の所これが自然かつモアベターな方法です。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
|
|
49
|
+
$ cd app
|
|
50
|
+
|
|
51
|
+
$ npm install
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
もし何か完璧な案を思いついたら試してみて下さい。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
---
|
|
40
62
|
|
|
41
63
|
|
|
42
64
|
|
|
@@ -70,10 +92,32 @@
|
|
|
70
92
|
|
|
71
93
|
|
|
72
94
|
|
|
73
|
-
|
|
95
|
+
> ライブラリ更新のたびにホストとコンテナで二重に実行する必要があるのでできれば避けたいです。
|
|
74
96
|
|
|
75
|
-
質問者さんがローカルでビルドする作りにしないほうが良いでしょう。
|
|
76
97
|
|
|
77
|
-
Webhookから[Drone](https://knowledge.sakura.ad.jp/2729/)等のCIでビルドしてデプロイする構成にするべきです。
|
|
78
98
|
|
|
99
|
+
これはおっしゃる通り。
|
|
100
|
+
|
|
101
|
+
実はモダンなプロジェクトではエンジニアが手作業でビルドすることは避けています。
|
|
102
|
+
|
|
103
|
+
(何が混入するかわからんし)
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
簡易的にやるならDockerHubとGitHubを連携させて、masterブランチが更新されたら自動的にdocker buildが走ってイメージが更新されるということが可能ですし、
|
|
108
|
+
|
|
109
|
+
凝ったことがしたければWebhookから[Drone](https://knowledge.sakura.ad.jp/2729/)等のCIツールを発火させて自動ビルドするような仕組みを構築しましょう。
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
79
|
-
その場合はnode_modulesディレクトリは`.gitignore`配下に含まれるはず
|
|
113
|
+
その場合はnode_modulesディレクトリは`.gitignore`配下に含まれるはずで、
|
|
114
|
+
|
|
115
|
+
`.dockerignore`で指定する必要すらなくなります。
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
GitHubなんかのmasterブランチが更新されたら、
|
|
120
|
+
|
|
121
|
+
CIツールが実行されて自動的にDockerImageが更新される。
|
|
122
|
+
|
|
123
|
+
これが勝ちパターンなので是非DroneやDockerHubの機能を覚えてみてください。
|