![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/02\/image-2.png?w=1024\")
<\/figure><\/div>\n\n\n\n\n\n\nLet’s Get Started<\/h3>\n\n\n\n
Refreshing basic concepts about Docker Images and Dockerfiles<\/p>\n\n\n\n
What is Dockerfile and Docker Image?<\/strong><\/h6>\n\n\n\nA Dockerfile is just a text file that contains the set of instructions to build a Docker image. Docker Image is a template that allows you to initiate running containers.<\/p>\n\n\n\n
What is Docker Layer and Docker build cache?<\/h6>\n\n\n\n
Each layer in a Docker context represents an instruction included in a Docker image’s Dockerfile. The layers can also be referred to as “build steps<\/strong><\/em>.”<\/p>\n\n\n\nEvery time you build a Docker image, each build step is cached. Reuse cached layers that do not change in the image rebuild process to improve the build time.<\/p>\n\n\n\n
Concerns when building images<\/h5>\n\n\n\n- Consistency:<\/strong> If we are consistently writing our Dockerfiles for our images, will be easier to maintain and we will reduce the time spent when developing new releases of the image<\/li>
- Build Time<\/strong>: Especially when our builds are integrated into a Continuous Integration pipeline (CI), reducing the build time can significantly reduce our apps’ development cost.<\/li>
- Image Size<\/strong>: Reduce the size of our images to improve the security, performance, efficiency, and maintainability of our containers.<\/li>
- Security<\/strong>: Critical for production environments, securing our containers is very important to protect our applications from external threats and attacks.<\/li><\/ul>\n\n\n\n
Can find more on Docker best practices<\/a><\/p>\n\n\n\nPrerequsistes : Docker Linter<\/h5>\n\n\n\n
A Linter helped us to detect syntax errors in our docker file and give us suggestions based on some best practices. We used OT-Dockerlinter<\/a> developed by our own team.<\/p>\n\n\n\nCase : Setting Up a Java Application onto Tomcat using Docker form Scratch<\/h5>\n\n\n\nBeing specific about your base image tag<\/strong> : <\/span><\/h5>\n\n\n\nMaintained images usually have different tags, used to specify their different flavors. For application, the maven<\/code> image is built as a base image. Maven has multiple versions in which it has a slim flavor that includes the minimal needed packages to run a Maven application (see multiple Supported Tags<\/a>).<\/p>\n\n\n\nFollowing this case, we used MVN_JDK_VERSION=3.6.0-jdk-11-slim with the minimal packages:<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2021\/03\/1.png?w=480\")
<\/figure>\n\n\n\nThis results in a lesser size of the whole image. Thanks to that finespun but important change, but don’t worry we can use any as per our requirements as we taking it as an Argument.<\/p>\n\n\n\n
Using multi-stage builds to separate build and runtime environments :<\/span><\/strong><\/h5>\n\n\n\nTo continue improving the efficiency, readability, and size of the image, we split the process into different stages : <\/p>\n\n\n\n
- Build Stage<\/strong> : Building the application from source code<\/li>
- Running Stage<\/strong> : Copy the application artifacts needed in the final stage and running the application.<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/02\/image-3.png?w=1024\")
<\/figure>\n\n\n\nThis is a short summary of what we have done :<\/p>\n\n\n\n
Using maven:3.6.0-jdk-11-slim to build our application, we added AS build<\/code> to name our first stage “build”<\/strong>. Then, we used COPY --from=build<\/code> to copy artifacts from that stage. That way, the artifacts copied are only the ones needed to run the minimal image. This approach is extremely effective when building images for compiled applications.<\/p>\n\n\n\nUsing the Non-Root Approach to Enforce Container Security<\/span><\/strong> :<\/strong><\/h5>\n\n\n\nNon-root containers add an extra layer of security. To put this in perspective, ask this:<\/p>\n\n\n\n
“Would we run any process or application as root in my server?” The answer, would be no, right? So why would we do so in our containers?<\/p><\/blockquote>\n\n\n\n
Running our containers as non-root prevents from gaining sudo privileges in the container host and if not so the repercussion could be bad when the application is deployed and made public, hackers can manipulate just not the application but the entire filesystem of the Docker container.<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2021\/03\/4.png?w=762\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Setting the WORKDIR instruction<\/span><\/strong> :<\/h5>\n\n\n\nThe default value for the working directory is \/<\/code>. However, unless we use FROM <\/code>scratch images, it is likely that the base image we are using set it. It is a good practice to set the WORKDIR instruction to adapt it to our application characteristics.<\/p>\n\n\n\nOur application server to get installed is under the directory \/opt<\/code>. Therefore, it makes sense to adapt the working directory to it :<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2021\/03\/5.png?w=709\")
<\/figure>\n\n\n\n And not only here, but we have also used WORKDIR at many more places.<\/p>\n\n\n\n
Say Hello to BuildKit <\/h5>\n\n\n\n
As our Dockerfile is a Multi-stage Build, when BuildKit comes across a multi-stage build it get concurrency, it analyzes the docker file and create a graph of the dependencies between build steps and uses this to determine which elements of the build can be ignored; which can be executed in parallel; and which need to be executed sequentially. To read more features of BuildKit<\/a><\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/02\/image-1.png?w=1024\")
<\/figure><\/div>\n\n\nTill the time, maven builds the artifact in the first stage, our second stage of downloading Tomcat of the specific version given as per user’s input is ready.<\/p>\n\n\n\n
Dockle – Container Image Linter for Security<\/h5>\n\n\n\n
Dockle performs multiple CIS benchmark checks, as well as more generic checks that are considered recommended best practices. Docker CIS Benchmark focuses on ensuring Docker containers runtimes are configured as securely as possible such as Host Configuration<\/em><\/strong>, Docker Daemon Configuration<\/em><\/strong>, Container<\/em><\/strong> Images,<\/em><\/strong> and Build File Configuration, etc. We have multiple tools for such security use cases<\/em><\/strong> Trivy, DockerSlim for latest CIS practices check the link<\/a><\/p>\n\n\n\n
Every time you build a Docker image, each build step is cached. Reuse cached layers that do not change in the image rebuild process to improve the build time.<\/p>\n\n\n\n
Concerns when building images<\/h5>\n\n\n\n- Consistency:<\/strong> If we are consistently writing our Dockerfiles for our images, will be easier to maintain and we will reduce the time spent when developing new releases of the image<\/li>
- Build Time<\/strong>: Especially when our builds are integrated into a Continuous Integration pipeline (CI), reducing the build time can significantly reduce our apps’ development cost.<\/li>
- Image Size<\/strong>: Reduce the size of our images to improve the security, performance, efficiency, and maintainability of our containers.<\/li>
- Security<\/strong>: Critical for production environments, securing our containers is very important to protect our applications from external threats and attacks.<\/li><\/ul>\n\n\n\n
Can find more on Docker best practices<\/a><\/p>\n\n\n\nPrerequsistes : Docker Linter<\/h5>\n\n\n\n
A Linter helped us to detect syntax errors in our docker file and give us suggestions based on some best practices. We used OT-Dockerlinter<\/a> developed by our own team.<\/p>\n\n\n\nCase : Setting Up a Java Application onto Tomcat using Docker form Scratch<\/h5>\n\n\n\nBeing specific about your base image tag<\/strong> : <\/span><\/h5>\n\n\n\nMaintained images usually have different tags, used to specify their different flavors. For application, the maven<\/code> image is built as a base image. Maven has multiple versions in which it has a slim flavor that includes the minimal needed packages to run a Maven application (see multiple Supported Tags<\/a>).<\/p>\n\n\n\nFollowing this case, we used MVN_JDK_VERSION=3.6.0-jdk-11-slim with the minimal packages:<\/p>\n\n\n\n<\/figure>\n\n\n\nThis results in a lesser size of the whole image. Thanks to that finespun but important change, but don’t worry we can use any as per our requirements as we taking it as an Argument.<\/p>\n\n\n\n
Using multi-stage builds to separate build and runtime environments :<\/span><\/strong><\/h5>\n\n\n\nTo continue improving the efficiency, readability, and size of the image, we split the process into different stages : <\/p>\n\n\n\n
- Build Stage<\/strong> : Building the application from source code<\/li>
- Running Stage<\/strong> : Copy the application artifacts needed in the final stage and running the application.<\/li><\/ul>\n\n\n\n
<\/figure>\n\n\n\nThis is a short summary of what we have done :<\/p>\n\n\n\n
Using maven:3.6.0-jdk-11-slim to build our application, we added AS build<\/code> to name our first stage “build”<\/strong>. Then, we used COPY --from=build<\/code> to copy artifacts from that stage. That way, the artifacts copied are only the ones needed to run the minimal image. This approach is extremely effective when building images for compiled applications.<\/p>\n\n\n\nUsing the Non-Root Approach to Enforce Container Security<\/span><\/strong> :<\/strong><\/h5>\n\n\n\nNon-root containers add an extra layer of security. To put this in perspective, ask this:<\/p>\n\n\n\n
“Would we run any process or application as root in my server?” The answer, would be no, right? So why would we do so in our containers?<\/p><\/blockquote>\n\n\n\n
Running our containers as non-root prevents from gaining sudo privileges in the container host and if not so the repercussion could be bad when the application is deployed and made public, hackers can manipulate just not the application but the entire filesystem of the Docker container.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/p>\n\n\n\n
Setting the WORKDIR instruction<\/span><\/strong> :<\/h5>\n\n\n\nThe default value for the working directory is \/<\/code>. However, unless we use FROM <\/code>scratch images, it is likely that the base image we are using set it. It is a good practice to set the WORKDIR instruction to adapt it to our application characteristics.<\/p>\n\n\n\nOur application server to get installed is under the directory \/opt<\/code>. Therefore, it makes sense to adapt the working directory to it :<\/p>\n\n\n\n<\/figure>\n\n\n\n And not only here, but we have also used WORKDIR at many more places.<\/p>\n\n\n\n
Say Hello to BuildKit <\/h5>\n\n\n\n
As our Dockerfile is a Multi-stage Build, when BuildKit comes across a multi-stage build it get concurrency, it analyzes the docker file and create a graph of the dependencies between build steps and uses this to determine which elements of the build can be ignored; which can be executed in parallel; and which need to be executed sequentially. To read more features of BuildKit<\/a><\/p>\n\n\n\n<\/figure><\/div>\n\n\nTill the time, maven builds the artifact in the first stage, our second stage of downloading Tomcat of the specific version given as per user’s input is ready.<\/p>\n\n\n\n
Dockle – Container Image Linter for Security<\/h5>\n\n\n\n
Dockle performs multiple CIS benchmark checks, as well as more generic checks that are considered recommended best practices. Docker CIS Benchmark focuses on ensuring Docker containers runtimes are configured as securely as possible such as Host Configuration<\/em><\/strong>, Docker Daemon Configuration<\/em><\/strong>, Container<\/em><\/strong> Images,<\/em><\/strong> and Build File Configuration, etc. We have multiple tools for such security use cases<\/em><\/strong> Trivy, DockerSlim for latest CIS practices check the link<\/a><\/p>\n\n\n\n
Can find more on Docker best practices<\/a><\/p>\n\n\n\n A Linter helped us to detect syntax errors in our docker file and give us suggestions based on some best practices. We used OT-Dockerlinter<\/a> developed by our own team.<\/p>\n\n\n\n Maintained images usually have different tags, used to specify their different flavors. For application, the Following this case, we used MVN_JDK_VERSION=3.6.0-jdk-11-slim with the minimal packages:<\/p>\n\n\n\n This results in a lesser size of the whole image. Thanks to that finespun but important change, but don’t worry we can use any as per our requirements as we taking it as an Argument.<\/p>\n\n\n\n To continue improving the efficiency, readability, and size of the image, we split the process into different stages : <\/p>\n\n\n\n This is a short summary of what we have done :<\/p>\n\n\n\n Using maven:3.6.0-jdk-11-slim to build our application, we added Non-root containers add an extra layer of security. To put this in perspective, ask this:<\/p>\n\n\n\n “Would we run any process or application as root in my server?” The answer, would be no, right? So why would we do so in our containers?<\/p><\/blockquote>\n\n\n\n Running our containers as non-root prevents from gaining sudo privileges in the container host and if not so the repercussion could be bad when the application is deployed and made public, hackers can manipulate just not the application but the entire filesystem of the Docker container.<\/p>\n\n\n\n <\/p>\n\n\n\n The default value for the working directory is Our application server to get installed is under the directory And not only here, but we have also used WORKDIR at many more places.<\/p>\n\n\n\n As our Dockerfile is a Multi-stage Build, when BuildKit comes across a multi-stage build it get concurrency, it analyzes the docker file and create a graph of the dependencies between build steps and uses this to determine which elements of the build can be ignored; which can be executed in parallel; and which need to be executed sequentially. To read more features of BuildKit<\/a><\/p>\n\n\n Till the time, maven builds the artifact in the first stage, our second stage of downloading Tomcat of the specific version given as per user’s input is ready.<\/p>\n\n\n\n Dockle performs multiple CIS benchmark checks, as well as more generic checks that are considered recommended best practices. Docker CIS Benchmark focuses on ensuring Docker containers runtimes are configured as securely as possible such as Host Configuration<\/em><\/strong>, Docker Daemon Configuration<\/em><\/strong>, Container<\/em><\/strong> Images,<\/em><\/strong> and Build File Configuration, etc. We have multiple tools for such security use cases<\/em><\/strong> Trivy, DockerSlim for latest CIS practices check the link<\/a><\/p>\n\n\n\nPrerequsistes : Docker Linter<\/h5>\n\n\n\n
Case : Setting Up a Java Application onto Tomcat using Docker form Scratch<\/h5>\n\n\n\n
Being specific about your base image tag<\/strong> : <\/span><\/h5>\n\n\n\n
maven<\/code> image is built as a base image. Maven has multiple versions in which it has a slim flavor that includes the minimal needed packages to run a Maven application (see multiple Supported Tags<\/a>).<\/p>\n\n\n\n<\/figure>\n\n\n\nUsing multi-stage builds to separate build and runtime environments :<\/span><\/strong><\/h5>\n\n\n\n
<\/figure>\n\n\n\nAS build<\/code> to name our first stage “build”<\/strong>. Then, we used COPY --from=build<\/code> to copy artifacts from that stage. That way, the artifacts copied are only the ones needed to run the minimal image. This approach is extremely effective when building images for compiled applications.<\/p>\n\n\n\nUsing the Non-Root Approach to Enforce Container Security<\/span><\/strong> :<\/strong><\/h5>\n\n\n\n
<\/figure>\n\n\n\nSetting the WORKDIR instruction<\/span><\/strong> :<\/h5>\n\n\n\n
\/<\/code>. However, unless we use FROM <\/code>scratch images, it is likely that the base image we are using set it. It is a good practice to set the WORKDIR instruction to adapt it to our application characteristics.<\/p>\n\n\n\n\/opt<\/code>. Therefore, it makes sense to adapt the working directory to it :<\/p>\n\n\n\n<\/figure>\n\n\n\nSay Hello to BuildKit <\/h5>\n\n\n\n
<\/figure><\/div>\n\n\nDockle – Container Image Linter for Security<\/h5>\n\n\n\n