51–60 of 107 posts
This approach is akin to installing all of the build tooling inside of Docker, then generating the build artifact. I'd think it'd be even slimmer to generate the build artifact first, then just copy that into the container. Is there an advantage to building inside of Docker?
in my eyes this is all madness. deploying sites via github to some docker shit. how about good old ftp and a cheap shared webhost? like its been done for 30 years.
To be honest, GitHub sites have been amazing for me. I just have a simple static website with personal information. HTML and CSS with minimal JS. Purchasing a shared webhost still means extra cost on top of domain registration. With GitHub, I just followed their instructions with my domain, and everything just worked. I'm also not paying anything per month or year besides domain registration which is really nice when…
> This docker image resulted in a 419MB final image and took about 3 minutes to build. There are some obvious issues with this. For instance every-time I change any file it must go through and reinstall all of my node_modules. He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?
Well, the article mentions an obvious improvement. The node_moduoes won't be rebuilt after any changes to the code, only changes specific to the packages.json. Basically the main step is the COPY . . step (previously COPY . /app) which will invalidate the cache every change to the code. Also that on the builder, the steps beyond npm run are not needed, but well they won't improve much on the performance or space of t…
But that's only if the builder image gets cached and can be reused, right?
This approach is akin to installing all of the build tooling inside of Docker, then generating the build artifact. I'd think it'd be even slimmer to generate the build artifact first, then just copy that into the container. Is there an advantage to building inside of Docker?
I have no idea why they need an nginx image in their second FROM, they are just doing some npm.
yeah, that is a mistake. I just did not fully rethink my code when I moved the build layers. I will be removing that tonight along with a few changed suggested here
For me the cause of the big image size was in
COPY --from=npmpackages /app /app
From your third Dockerfile, it seems replacing the above with the following would have done the trick without adding an extra stage
COPY --from=npmpackages /app/_site/ /usr/share/nginx/html/
Static site and docker shouldn’t be seen together.
Static site and docker shouldn’t be seen together.
> This docker image resulted in a 419MB final image and took about 3 minutes to build. There are some obvious issues with this. For instance every-time I change any file it must go through and reinstall all of my node_modules. He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?
You can probably shrink it even more. The Caddy alpine image is 14MB compressed. https://hub.docker.com/_/caddy/ You also get automatic TLS certificate management and tons of other goodies that nginx doesn't offer out of the box.
I missed the whole Caddy thing anyway because the source code was not completely open back in the days I was looking for nginx alternatives that provided with LetsEncrypt automatically.
However, it seems Caddy can be used as an alternative to Traefik if you use a plugin: https://caddyserver.com/v1/docs/docker Apparently it requires swarm though, which I don't need anyway, so, still no reason for me to try Caddy unfortunately because it does look pretty cool now.
in my eyes this is all madness. deploying sites via github to some docker shit. how about good old ftp and a cheap shared webhost? like its been done for 30 years.
That doesn't have enough buzzwords.