I’ve been on a bit of a Docker kick lately. Mostly to help my team reduce the time it takes to get up and running on a project. The end goal here being that, where possible, we’ll have containerized development and deployment environments.
A lot of this drive has come from needing to pick up a few older projects and encountering a number of issues getting these projects up and running. Some of these projects needed older versions of node, grunt or gulp installed to work correctly. Had the development environments for these projects been properly containerized a lot of the issues encountered could have been mitigated
As we’re using Angular and @angular/cli for a few of our front-end projects I’ve started there.
There are a number of public images available on Docker Hub that can provide a containerized runtime for you toolchain. I’ll use the teracy/angular-cli image in my examples here as it’s pretty well supported, allows for running tests, and is kept up to date by it’s maintainer.
In this post I’ll walk through getting a containerized dev environment set up and a few changes that you will need to make to your Angular project to have it run well under this arrangement.
Spin up your container
First of all make a new directory on the command line, move into and spin up your container…
mkdir my-new-app cd my-new-app docker run -it --rm -p 4200:4200 -p 49153:49153 -v ${pwd}:/my-new-app teracy/angular-cli /bin/bash
Assuming that you don’t already have the teracy/angular-cli image already this will pull down the image and launch a new container for you. This command also mounts the directory on your host machine in which you want to store your source code in the file system of the container as /my-new-app.
Next we’ll use the @angular/cli tools to spin up an new Angular project.
Scaffold your Angular App
ng new my-new-app –-skip-install cd my-new-app npm install
For some reason the npm install step in ng new always fails for me, so this sequence dodges that issue. That will take a little while as it pulls down all the necessary node modules from npm. Let’s take advantage of this time to make some changes.
Make ng serve work as expected
- Open the my-new-app using your editor of choice from the host machine.
- Open the package.json file
- Change the start entry in the scripts object to read
ng serve –host 0.0.0.0 –poll 2000
This change binds the dev web server to listen to all requests on the default port (4200) and ensures that file changes made from the host machine are detected from the container for the purposes of automatic rebuilds.
Inside the container run up the development server by running this command:
npm start
From your host machine you can now go to http://localhost:4200 and you’ll see the skeleton app served to your browser. If you make changes to the code you’ll see a rebuild triggered when you save your changes.
All good so far. If this is all your want to do then you can even use my extremely light weight image gavinbarron/ng-cli-alpine.
Configure for running tests
However if you want to run tests then there’s still a little more to do and my image won’t meet your needs. Let’s get the tests running successfully.
Open the karma.conf.js file and add the section below after the browsers entry:
customLaunchers: { Chrome_no_sandbox: { base: 'Chrome', flags: ['--no-sandbox'] } },
Save all your changes and run in the container (Use Ctrl + C to stop the web server if you need to):
ng test --browsers Chrome_no_sandbox
Conclusion
I’ve seen you how easy it is to get a development environment for Angular up an running in a Docker container. You could take this further with docker-compose and a .yaml file as outlined in this great post that helped me get up and running: http://blog.teracy.com/2016/09/22/how-to-develop-angular-2-applications-easily-with-docker-and-angular-cli/
–poll consumes a lot of cpu it doesnt solve the root problem. Why on Linux it works without poll flag?
I have noticed the CPU usage is up a bit, but it’s not like it’s hurting me on my machine.
I strongly suspect that we’re seeing that the –poll option is needed on a Windows machine due to the fact that the disk systems are so very different. Remember that you’re actually running a Linux VM on Windows here to provide the Docker host machine so this issue doesn’t surprise me entirely.