It is important to realize that Docker is inherently a '''Linux''' technology. [https://docs.docker.com/engine/ Docker Engine] is an open source containerization technology for building and containerizing your applications. Docker Engine acts as a client-server application with: * A server with a long-running daemon process <code>dockerd</code>.* APIs which specify interfaces that programs can use to talk to and instruct the Docker daemon.* A command line interface (CLI) client <code>docker</code>. The CLI uses Docker APIs to control or interact with the Docker daemon through scripting or direct CLI commands. Many other Docker applications use the underlying API and CLI. The daemon creates and manage Docker objects, such as images, containers, networks, and volumes. For more details, see [https://docs.docker.com/get-started/overview/#docker-architecture Docker Architecture].{{#ev:youtube|YFl2mCHdv24|480|right}}
{{#ev:youtube|Qw9zlE3t8Ko|480|right}}
*https://docs.docker.com/engine/install/
== Volumes and Mounts ==
From [https://docs.docker.com/storage/ Data management in Docker]<blockquote>By default all files created inside a container are stored on a writable container layer. This means that:
That is all you need to know about Docker when it comes to sharing files between the host and the container.
Volumes are the preferred way to persist data in Docker containers and services.
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.
When you use either bind mounts or volumes, keep the following in mind:
* If you mount an '''empty volume''' into a directory in the container in which files or directories exist, these files or directories are propagated (copied) into the volume. Similarly, if you start a container and specify a volume which does not already exist, an empty volume is created for you. This is a good way to pre-populate data that another container needs.
* If you mount a '''bind mount or non-empty volume''' into a directory in the container in which some files or directories exist, these files or directories are obscured by the mount, just as if you saved files into <code>/mnt</code> on a Linux host and then mounted a USB drive into <code>/mnt</code>. The contents of <code>/mnt</code> would be obscured by the contents of the USB drive until the USB drive were unmounted. The obscured files are not removed or altered, but are not accessible while the bind mount or volume is mounted.
== VSCode with Docker ==
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==
Bitnami has a [https://github.com/bitnami/bitnami-docker-mediawiki Docker Image for MediaWiki]