1

I'm running a Rails backend with Angular front end inside of a Docker image. The host machine is running OSX.

The services come up fine when I run docker-compose up --build but any changes to the front end files take nearly an hour to trigger a hot reload.

If I run the build process manually in a bash session for the ng container, (ng build --aot), it takes about 2 minutes. Not optimal, but better than an hour. That same build process takes way longer when it's part of a hot reload. I'm not sure why.

I tried the solution mentioned here, about opening up the port for webpack hot reloads and adding the port number inside docker-compose.yml but I saw no difference in behavior.

The Rails part of this works fine. Changing a file is almost immediately noticed in the container.

But things aren't as snappy for the ng container. The node_modules directory is excluded from my Docker image, so when Docker builds, it populates its own node_modules directory inside the image. That should mean that there are no issues syncing node modules on the host machine with what's in the image.

I've done some research and it looks like there's an option to run ng eject, which would enable me to customize the webpack config. There are a few suggestions about modifying the config to speed things up, e.g. this one. However, given that the eject option isn't supported in ng 6, I'd prefer not to go down this road.

Any ideas on how I can speed up the compilation time for this ng app?

Ben Downey
  • 2,575
  • 4
  • 37
  • 57

1 Answers1

0

This comment on the AngularCLI issue "ng serve not detecting file changes" solved the issue.

Updating the tsconfig.json file so that it automatically excludes the node_modules directory sped up webpack immensely.

I'm still curious why this it was an issue on Debian Jessie but not on OSX. If anyone knows the reason, I'm all ears.

Ben Downey
  • 2,575
  • 4
  • 37
  • 57
  • Were you running Docker via OSX, with your source code mounted in a volume? The volume performance will have impacted the speed, whereas running natively on Mac OS would have had no overhead of syncing files – Steve Vaughan Aug 09 '18 at 16:07
  • I was wondering about that. But if it were a file syncing issue, I would expect the Rails app to suffer from the same latency. It's odd that this only affected the Angular app. In addition, the Docker image runs its own npm install and doesn't know about the host machine's `node_modules` directory (it was added to the `.dockerignore` file). So there's no syncing of anything from that directory between the host machine and the Docker image. – Ben Downey Aug 09 '18 at 20:08
  • Dockerignore is only used when building images, were you using a prebuilt image and mounting a volume, or building your own? I got caught out by this! – Steve Vaughan Aug 09 '18 at 20:13
  • I was building my own image. I had a line in the Dockerfile where I added everyhting in the repo's root directory, but I assumed that since I was ignoring via the `dockerignore` file, it was also going to be ignored while the containers ran. But you're saying that the `dockerignore` file is ignored once the containers are up and running. Is that correct? – Ben Downey Aug 10 '18 at 03:47
  • If you declare a volume when running your container or via docker-compose, I believe that will then ignore .dockerignore. – Steve Vaughan Aug 10 '18 at 07:11