![]() ![]() The main changes from original Dockerfile is having to separate yarn install and yarn build things, which makes sure that if you have changed yarn.lock or package.json we will rebuild Docker image layer responsible for having node_modules otherwise it will stay the same and we don’t have to upload that or download from Registry if we already have. Which comes down of having something like this for our Node.js Typescript project Main idea here is to keep your Docker image with the same unique image layers so that ONLY changed layers would be uploaded to Registry and only changed layers would be downloaded from there. , but overall it wouldn’t make that match of a difference. Make sure to keep unique Docker Image layers for not rebuilding entire image layers all the time when you have a slight changeįor the 1st point we already have pretty match the bare minimum Docker image, which means we probably can remove some unnecessary files from Dockerfile like README.md.So, the idea of having an optimised Docker image comes down to this following 2 points This is also means if you have for example a staging environment or Github Actions for running your automated tests, it will take a lot less time if you have smaller images with a less build times. In microservice world it is considered a good practice of having small Docker images for faster deployments and faster uptimes on server side. ![]() If you have a Node Typescript project like I have here this will work perfectly fine, especially if alpine itself is quite small base image, the only storage that you have to acquire is your node_modules, which of-course could grow to few GB’s if you have even 20+ packages in your dependencies.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |