Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Docker best Practices

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
what is OSI model
what is OSI model
Wird geladen in …3
×

Hier ansehen

1 von 15 Anzeige

Weitere Verwandte Inhalte

Weitere von jeetendra mandal (20)

Aktuellste (20)

Anzeige

Docker best Practices

  1. 1. Docker development Best Practices 1.CI/CD for Testing and Deployment: Experts recommend using Docker Hub or any other CI/CD pipeline to build and tag a Docker image whenever a pull request is created. Furthermore, the images should be signed by the development, security, and testing teams before they are pushed to production so that it is constantly tested for quality by the desired teams. 2.Use Different Environments for Development and Testing: One of the best practices while using Docker for development is creating different testing and development environments. Doing so will allow the developer to keep the Docker files isolated and execute them without influencing the final build after testing. 3.Update Docker to the Latest Version: Before you begin working on a Docker project, you need to ensure that you update the Docker to the latest version. Even though it will not directly impact the project, it will provide you with the latest features that Docker has to offer. New updates also have certain security features, safeguarding the project from potential attacks
  2. 2. Docker container Best Practices 1.Frequently Backup a Single Manager Node: A common Docker container practice is to back a single managed node frequently, which helps admins in restoration. Docker Swarm and Universal Control Plane data are part of every node, so backing up a single manager node can get the job done for the admins. 2.Cloud Deployment of a Docker Container: When deploying a Docker container to a cloud, both Amazon Web Services and Microsoft Azure do not have integrated hosts optimized for Docker. They use the Kubernetes cluster for deployment. A standard virtual machine should be created by the admins who prefer to deploy a single container. Apart from that, securing the secure socket shell and installing Docker is the next step. Admins can now deploy the application on a cloud after installing Docker. 3.Control Docker Containers through a Load Balancer: A load balancer helps admins get good control over Docker containers which helps them in making containers highly available and scalable. The most commonly used load balancer is NGINX which can easily be installed on Docker. This load balancer supports multiple balancing methods, static and dynamic caching, rate limiting, and multiple distinct applications.
  3. 3. 1. Beware of inheritance and dependencies Your containers inherit a parent image that generally includes its base operating system and dependencies—things like dependent packages, default users, etc. Those inherited attributes and dependencies might expose your containers to unnecessary risk. Make sure you’re aware of the inherited attributes and take any additional steps necessary to further isolate and protect your containers. 2. Limit container interaction Container security has emerged as a serious concern for many organizations—specifically how containers interact with one another and with the outside world. Your containers should not accept connections on exposed ports through any network interface. You should take steps both to control how—and how much—containers interact with each other internally, and limit the number of containers that have contact with the outside world so you can minimize exposure to external risks.
  4. 4. 3. Monitor containers for vulnerabilities One of the challenges of using a code repository like Docker Hub is that once a container image is uploaded to the repository nobody takes responsibility for keeping it patched and secure. It might be fine when originally created, but over time new vulnerabilities and exploits are discovered and you need to scan for those before using containers in production. A tool like Twistlock can help you monitor for and identify vulnerabilities in your container images. 4. Run containers as read only where possible One of the best and simplest ways to limit exposure to risk for container is to run them in read-only mode. That obviously won’t work for all containers—there will be containers that must accept input of some sort in order for apps to work, but containers that can be run in read-only mode should be. You should also never run containers in privileged mode.
  5. 5. Docker Logging best practices 1.Logging from Application: Logging directly from the application is a method where applications within the container manage the logging through a framework. The developers will have the utmost control over the logging event when using this method. 2.Logging Drivers: Logging drivers is a unique feature of Docker that helps read data by the stderr or stdout streams of the container as they are specifically configured to accomplish this task. Once done, the host machine stores log files that include the prior data. 3. Dedicated Container for Logging: Having a dedicated container for logging helps in eradicating dependencies on host machines. This container will be responsible for log file management within the Docker environment. 4.Sidecar Method: The Sidecar method is undoubtedly among the best if you want to manage microservices architecture. Here, the sidecars run simultaneously with the parent application, where they share the same network and volume. These shared resources allow you to expand the app functionalities and eradicate the need to install any extra configurations.
  6. 6. Dockerfile When using containers to deploy your applications, one of the most important things that you must get right is your Dockerfiles. Dockerfiles are how you tell Docker how to build and deploy your containers. If they aren’t well-written or optimized for your needs, that can significantly impact how quickly and efficiently you can get new versions of your application up and running.
  7. 7. Dockerfile Best Practices - Do not use your Dockerfile as a build script: A Dockerfile is a set of instructions that can be used to create a custom image. It should never be used as a build script because it will make your builds unnecessarily long. When you must compile or bundle software in your Dockerfile, you should use the ADD instruction. This will copy the files necessary for compilation into the image before it starts running commands. This will let you keep the Dockerfile short and manage any dependencies required for compilation separately from the Dockerfile. - Use ENV to define environment variables: Setting environment variables is a best practice for Dockerfiles. Although it might seem like a small detail, defining your environment variables will make your containers more portable. This is because your environment variables are the only thing that can change from one execution to the next. If you have a variable that must be different both inside and outside of your container, then you must define it using ENV.
  8. 8. Dockerfile Best Practices - Commit your Dockerfile to the repository: One of the best practices of Dockerfiles is committing them to your repository. This lets you easily and quickly reference it later without remembering all of the commands that you used or what their order was. - Be mindful of your base image and its size: One of the most important things to consider when creating your Dockerfile is the base image that you’re using. It will increase your Docker image's size if you have a lot of extraneous code. This will make it much slower for your container to start up or, even worse, prevent it from starting at all. The best way to avoid this is by being mindful of which packages and scripts you use. If it doesn’t seem necessary to include it in the base image, try and find a way to install it when the container starts up instead. This will save space on your container, thus making it run more quickly and efficiently.
  9. 9. Dockerfile Best Practices - Do not expose secrets: Never share or copy the application credentials or any sensitive information in the Dockerfile. Instead, use the .dockerignore file to prevent copying files that might contain sensitive information. The .dockerignore file acts as equivalent to the .gitignore file, and it lets you specify the files that you want the build process to ignore. - Be mindful of which ports are exposed: When designing your Dockerfile, make sure that you know which ports are exposed. By default, Docker will expose all of the containers to a range of random internal ports. This is problematic, as it can expose critical services to the outside world and leave them open for attack. If you’re using a service that must be exposed to the public internet, then you must create an entry in the Dockerfile. This is done by adding 'EXPOSE' in your Dockerfile.
  10. 10. Docker image building Best Practices Version Docker Images:A common practice among Docker users is using the latest tag for images which is also the default tag for images. Using this tag will eradicate the possibility of identifying the running version code based on the image tag. Not only does it become easier to overwrite it, but it also leads to extreme complications while doing rollbacks. Make sure to avoid using the latest tag, especially for base images, as it could unintentionally lead to the deployment of a new version. Rather than using the default tag, the best practice is to use descriptors like semantic version, timestamps, or Docker image IDs as a tag. With the practice of having a relevant tagging scheme, it becomes easier to tie the tag to the code.
  11. 11. Docker image building Best Practices Avoid Storing Secrets in Images: Undeniably, confidential data or secrets like SSH keys, passwords, and TLS certificates are highly sensitive for an organization. Storing such data in images without encryption can make it easier for anyone to extract and exploit it. This situation is extremely common when images are pushed into a public registry. Rather than that, injecting these through build-time arguments, environment variables, and an orchestration tool is the best practice. In addition, sensitive data can also be added to the .dockerignore file. Another practice to accomplish this goal is by being specific about the files that should be copied over the image. Environment Variables:Environment variables are primarily used to keep the application flexible and secure. These can also be used to pass on sensitive information or secrets. However, these will still be visible in the logs, child processes, linked containers, and docker inspect. The following is a frequently used approach for managing secrets.
  12. 12. Docker image building Best Practices Using a .dockerignore File: The .dockerignore file is used to define the required build context. Before an image is built, the user has to specify the files and folders that should be excluded from the initial build context sent to the Docker daemon which is done with the help of the .dockerignore file. Prior to evaluating the COPY or ADD commands, the entire project’s root is sent to the Docker daemon, making it a hefty deal. Apart from that, there can be stances when the daemon and the Docker CLI are on different machines. In that case, the .dockerignore file should be added to local secrets, temporary files, local development files, or build logs. Doing so can boost the build process, avoid secret leaks, and reduce the Docker image size. Image Linting and Scanning: Inspecting the source code for any stylistic or programmatic error that can cause issues is called lining. Linting can help ensure that the Dockerfiles comply with the right practice and can be maintained. This process can also be followed in images to determine any underlying vulnerabilities or issues.
  13. 13. THANK YOU Like the Video and Subscribe the Channel

×