pfooti
pfooti

Reputation: 2704

Is it a bad idea to use docker to run a front end build process during development?

I have an angular project I'm working on containerizing. It currently has enough build tooling that a front-end developer could (and this is how it currently works) just run gulp in the project root, edit source files in src/, and the build tooling handles running traceur, templates and libsass and so forth, spitting content into a build directory. That build directory is served with a minimal server in development, and handled by nginx in production.

My goal is to build a docker-based environment that replicates this workflow. My users are developers who are on different kinds of boxes, so having build dependencies frozen in a dockerfile seems to make sense.

I've gotten close enough to this- docker mounts the host volume, the developer edits the file on the local disk, and the gulp build watcher is running in the docker container instance and rebuilds the site (and triggers livereload, etc etc).

The issue I have is with wrapping my head around how filesystem layers work. Is this process of rebuilding files in the container's build/frontend directory generating a ton of extraneous saved layers? That's not something I'd really like, because I'm not wild about monotonically growing this instance as developers tweak and rebuild and tweak and rebuild. It'd only grow locally, but having to go through the "okay, time to clean up and start over" process seems tedious.

Upvotes: 1

Views: 952

Answers (1)

Kevan Ahlquist
Kevan Ahlquist

Reputation: 5533

Is this process of rebuilding files in the container's build/frontend directory generating a ton of extraneous saved layers?

Nope, the only way to stack up extra layers is to commit a container with changes to a new image then use that new image to create the next container. Rinse, repeat.

Filesystem layers are saved when a container is committed to a new image (docker commit ...). When a container is running there will be a single read/write layer on top that contains all of the changes made to the container since it was created.

having to go through the "okay, time to clean up and start over" process seems tedious.

If you run the build container with docker run --rm ... then you'll get the cleanup for free. The build container will be created fresh from the image each time.

Also, data volumes bypass the union filesystem so there's a good chance you won't write to the container's filesystem at all.

Upvotes: 2

Related Questions