Following , here is a protip that will significantly boost your build time of your brand new dockerized dev environment. part 1 1. What, it wasn't perfect already ? we ended up with the following Dockerfile: In part 1 Now let's have a look at what happens when you install a new package (in this example this corresponds to changing the file). We're going to install the 'twit' package. Because why not. If you understood the part 1, then you probably figured out that you have to run the command from within the container (since there is no such thing as on our computer, is it?): package.json npm install npm docker-compose run hello npm install --save twit a will show that the package.json has changed. We now have to rebuild our images with git status docker-compose build Which will trigger a fresh install. But there is a catch : npm install is run For a medium to big sized project, this can really take a long time. And so does for rubyists. from scratch. gem install Furthermore, it will also take long for the CI server to build your image and your tests won't be as fast as you would like them to be. This can definitely be improved. 2. Make it faster ! If you take a closer look at our , then you'll see everything starts with a command_._ Dockerfile FROM:mhart/alpine-node This basically means that we start with a docker image that already contains node, and some basic unix tools (try it out, you can run commands such as although we never specifically installed them). ls, echo, pwd…etc => What if we build our own image, that would already contain some packages ? node_modules I'm glad you asked. Let's do this this way : Build an image that contains node + a pre-installation of our current libraries Push this image to docker-hub so it's available for everyone (or for the team & CI servers if you do use a private image) Use this image in the FROM instruction of our Dockerfile Build our current project by taking advantage of the pre-installed libraries Enjoy lightning-fast builds ! Let's roll back and do it the right way. A complete working directory can be found : here git clone --branch faster https://github.com/aherve/simple-dockerized-dev-env First of all, let's prepare a At this point you should simply use your current file. It means everything listed under this package.json file are going to be installed in your bootstrap image. If you decide to change it further, then only the additional packages will have to be installed by the command. base-package.json. package.json docker-compose build With this we can build our bootstrap image, that we describe in the file: Dockerfile.bootstrap Now that you are beginning to get familiar with the Dockerfiles, you can see that we are simply taking our base-package.json, and installing the dependencies in the directory . /tmp/node_modules of the container At this point you should build this image, and send it to docker-hub so it becomes available under . your-login/my-app-bootstrap For the purpose of the demonstration, let's simply build the image locally and prove it is working: docker build -t bootstrap_demo -f Dockerfile.bootstrap . Alright, it built. We don't really care about how much time it takes, we are only going to build it once for all. Next, let's modify our main Dockerfile as follows: Build our brand new image: docker-compose build Did you notice how did not have anything to do here ? Definitely faster than re-installing all your dependencies ! npm install Does it work ? (spoiler: it does) docker-compose run test count ✓ should return 1 1 passing (10ms) And now the final : let's change our package.json and see what happens : docker-compose run hello npm install --save twitdocker-compose build And *Voilà*, we successfully installed the package in no-time ! twit You can check that it worked: docker-compose run hello npm list | grep twit> `-- twit@2.2.3docker-compose run test hello is loaded ! count ✓ should return 11 passing (9ms) Now when you trigger a fresh build that uses your Dockerfile, only will have to be reinstalled. twit When you are tired to install it, simply add it to the build a new bootstrap image that you tag with a different version, and tell your Dockerfile to use it. base-package.json, This is actually simply a docker implementation of what you are used to do everyday : When you run npm install, it it quite fast, you previously removed your In this case, it has to rebuild everything from scratch. unless node_modules. This trick is just as good for ruby developers, since is strictly equivalent to a package.json Gemfile Conclusion: This concludes our tutorial. As you can see, it is not that difficult to build a fast, light, and efficient environment using docker. We did not have to compromise any of the features we previously had (like hot-reloading, automated-testing…etc), but we got in addition to this : development standardized environments one-click install reproductible CI-test on any computer Although we did not speak about production deployment here, you can easily imagine that it is quite straightforward to push the build container to some docker-hosting platform. from the CI/CD server At we set up a workflow using codeship that consist of Hunteed develop something, and test it locally push to github webhook is triggered and codeship test it the same way if codeship succeeded to build the image, and if the image proved it can pass the testing-suite, then push this very image to docker-hub Either set a docker-hub trigger, or trigger a redeployment of your image on some docker-hosting platform. Your code is up to date and in production. With such a workflow, and together with proper code coverage, it becomes quite straightforward to deploy several times a week. Hope this helped, If you want to see a more real-life environment, you can have a look at this dockerized typescript-node-express build Happy coding! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
