Docker: Difference between revisions
→Docker in Docker: more security focus |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
It is important to realize that Docker is inherently a '''Linux''' technology. | It is important to realize that Docker is inherently a '''Linux''' technology. | ||
'''Key aspects of containers''' | |||
;Portability: | |||
:Containers (or at least the image that created it) can be easily moved and run on different machines and environments without modification, ensuring consistent behavior. | |||
;Isolation: | |||
:Each container runs in its own isolated environment, preventing conflicts between different applications and improving security. | |||
;Lightweight: | |||
:Containers share the host operating system's kernel, making them smaller and faster to start than virtual machines. | |||
;Scalability: | |||
:Containers can be easily scaled up or down to meet the demands of an application. | |||
;Automation: | |||
:Containers are often used in conjunction with container orchestration platforms like [[Kubernetes]] to automate application deployment and management. | |||
| Line 43: | Line 61: | ||
Note: '''Docker Desktop''' is simply a fancy GUI '''client''' application that uses virtualization (a Linux Virtual Machine) to bundle the Docker Engine into your host OS. | Note: '''[[Docker Desktop]]''' is simply a fancy GUI '''client''' application that uses virtualization (a Linux Virtual Machine) to bundle the Docker Engine into your host OS. | ||
*Volumes are the right choice when your application requires fully native file system behavior on Docker Desktop. For example, a database engine requires precise control over disk flushing to guarantee transaction durability. Volumes are stored in the Linux VM and can make these guarantees, whereas bind mounts are remoted to macOS or Windows OS, where the file systems behave slightly differently. | *Volumes are the right choice when your application requires fully native file system behavior on Docker Desktop. For example, a database engine requires precise control over disk flushing to guarantee transaction durability. Volumes are stored in the Linux VM and can make these guarantees, whereas bind mounts are remoted to macOS or Windows OS, where the file systems behave slightly differently. | ||
| Line 57: | Line 75: | ||
Each time you create a Docker container, and connect VSCode to that container, VSCode installs a server into the container so that it can communicate with it. So, there is a small (a couple minutes?) delay while this happens before you can edit or do anything. Best to stop a container and only re-build it when necessary to avoid the delay. | Each time you create a Docker container, and connect VSCode to that container, VSCode installs a server into the container so that it can communicate with it. So, there is a small (a couple minutes?) delay while this happens before you can edit or do anything. Best to stop a container and only re-build it when necessary to avoid the delay. | ||
==Docker Images== | ==Docker Images== | ||
The primary resource for Docker Images is '''Docker Hub''', but every major cloud provider has some sort of repository for storing and versioning your images. For example, if you're hosting your code on GitHub and using GitHub Actions for CI/CD, there is the GitHub Container Registry (GHCR)<ref>(GitHub now generalizes the discussion to 'packages' since you might be creating Docker OCI images, NPM Node.js packages, or Ruby Gems) https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry</ref>. | |||
Bitnami had a Docker Image for MediaWiki. Don't use Bitnami. You will thank me later.<ref>I told you so. They weren't very good when they were available, and now they're not freely available at all. Bitnami has shifted to a paid offering.</ref> | |||
==Security== | ==Security== | ||
| Line 63: | Line 83: | ||
== Docker Downsides == | == Docker Downsides == | ||
One major negative to the system architecture of Docker is that it relies on a server daemon. | One major negative to the system architecture of Docker is that it relies on a server daemon. '''Unlike''' [[Podman]], Docker's Engine can use up 4GB of RAM just sitting idle. A similar thing happens with WSL2 on Windows <ref>https://news.ycombinator.com/item?id=26897095</ref> | ||
A similar thing happens with WSL2 on Windows <ref>https://news.ycombinator.com/item?id=26897095</ref> | |||
== Future Reading == | == Future Reading == | ||