Docker - Revision history

Leo: /* docker_gwbridge */

2021-07-07T00:10:12Z

docker_gwbridge

← Older revision		Revision as of 00:10, 7 July 2021
Line 528:		Line 528:
	systemctl enable docker-volume-netshare		systemctl enable docker-volume-netshare
	systemctl start docker-volume-netshare		systemctl start docker-volume-netshare
	\| lang = ~~terminal~~		\| lang = bash
	}}		}}

Leo: Docker NFS volumes

2021-07-07T00:09:11Z

Docker NFS volumes

← Older revision		Revision as of 00:09, 7 July 2021
Line 484:		Line 484:
	brctl delbr docker_gwbridge		brctl delbr docker_gwbridge
	systemctl start docker		systemctl start docker
	-->===~~Mounting~~ NFS in Docker===		-->===NFS volumes in Docker===
	The docker-volume-netshare ~~utility~~ provides a ~~convenient method of mounting~~ persistent volumes ~~to your docker container~~.		The docker-volume-netshare Docker plugin (https://github.com/ContainX/docker-volume-netshare) automates the mounting/unmounting of NFS mounts as containers come and go. This provides a way to mount persistent volumes via NFS.

	~~See https~~:~~//github.com/ContainX/docker-volume-netshare~~		The easiest way to get this is to download one of their releases. Alternatively, you may compile it within a golang:latest container:

	~~Can't build it on CentOS, get this error:~~		{{Highlight
	{{~~highlight\|lang=terminal~~\|code=		\| code = # docker run --rm -ti -v ./build:/build golang:latest bash
	# ~~go build github.com/ContainX/~~docker-~~volume~~-~~netshare~~		$ go get github.com/ContainX/docker-volume-netshare
	~~src/github.com/ContainX/docker~~-~~volume~~-~~netshare/netshare/drivers/ceph.go:44: undefined: volume~~.~~Response~~		$ cp /go/bin/docker-volume-netshare /build
	~~src~~/~~github.com/ContainX/docker-volume-netshare/netshare/drivers/ceph.go:68: undefined~~: ~~volume.Response~~		\| lang = terminal
	~~src~~/~~github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.go:76: undefined~~: ~~volume.Response~~
	~~src/github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.~~go~~:128: undefined: volume.Response~~
	~~src/~~github.com/ContainX/docker-volume-netshare~~/netshare/drivers/driver.go:23: undefined: volume.Response~~
	~~src/github.com/ContainX~~/~~docker-volume-netshare/netshare/drivers/driver.~~go~~:23: undefined: volume.Request~~
	~~src/github.com~~/~~ContainX~~/docker-volume-netshare/~~netshare/drivers/driver.go:47: undefined: volume.Response~~
	~~src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:47: undefined: volume.Request~~
	~~src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Response~~
	~~src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Request~~
	~~src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: too many errors~~
	}}		}}

	~~Using binaries from https://github.com/ContainX/docker-volume-netshare/releases~~, ~~then use this script~~ to ~~install~~ it ~~on the system~~:		Once you have the binary on hand, set up a systemd service to start it automatically.
	{{~~highlight\|lang=bash~~\|code=
	#!/bin/bash		On CentOS:

			{{Highlight
			\| code = #!/bin/bash

	cp docker-volume-netshare /usr/bin/docker-volume-netshare		cp docker-volume-netshare /usr/bin/docker-volume-netshare

	echo "DKV_NETSHARE_OPTS=nfs" > /etc/sysconfig/docker-volume-netshare		echo "DKV_NETSHARE_OPTS=nfs" > /etc/sysconfig/docker-volume-netshare

	cat <<EOF > /usr/lib/systemd/system/docker-volume-netshare.service		cat <<EOF > /usr/lib/systemd/system/docker-volume-netshare.service
	[Unit]		[Unit]
Line 532:		Line 528:
	systemctl enable docker-volume-netshare		systemctl enable docker-volume-netshare
	systemctl start docker-volume-netshare		systemctl start docker-volume-netshare
			\| lang = terminal
	}}		}}

			On Ubuntu/Debian, the sysconfig directory is located in <code>/run/sysconfig</code>. Adjust the paths above as required.
	===TFTP inside Docker===		===TFTP inside Docker===
	If you're going to run a TFTP server, you need ip_conntrack_tftp and ip_nat_tftp loaded. Otherwise, the firewall will just block everything:		If you're going to run a TFTP server, you need ip_conntrack_tftp and ip_nat_tftp loaded. Otherwise, the firewall will just block everything:
Line 560:		Line 557:
	}}		}}

	=== Pruning old logs ===		===Pruning old logs===
	Truncate all docker logs by running:		Truncate all docker logs by running:
	{{Highlight		{{Highlight

Leo: truncate old logs

2021-05-03T17:55:56Z

truncate old logs

← Older revision		Revision as of 17:55, 3 May 2021
Line 91:		Line 91:
	Install docker using your distro's package manager and then start the service.		Install docker using your distro's package manager and then start the service.

	=== CentOS ===		===CentOS===
	{{Highlight		{{Highlight
	\| code = # yum install -y yum-utils		\| code = # yum install -y yum-utils
Line 102:		Line 102:
	}}		}}

	=== Fedora ===		===Fedora===
	On a Fedora distro (https://docs.docker.com/engine/installation/linux/docker-ce/fedora/#install-using-the-repository):		On a Fedora distro (https://docs.docker.com/engine/installation/linux/docker-ce/fedora/#install-using-the-repository):
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
Line 557:		Line 557:
	{{Highlight		{{Highlight
	\| code = /5 * * * docker restart $(docker ps {{!}} grep unhealthy {{!}} cut -c -12) 2>/dev/null		\| code = /5 * * * docker restart $(docker ps {{!}} grep unhealthy {{!}} cut -c -12) 2>/dev/null
			\| lang = terminal
			}}

			=== Pruning old logs ===
			Truncate all docker logs by running:
			{{Highlight
			\| code = # truncate -s 0 /var/lib/docker/containers/$1/-json.log
	\| lang = terminal		\| lang = terminal
	}}		}}

Leo: /* Installation */

2021-02-15T22:54:05Z

Installation

← Older revision		Revision as of 22:54, 15 February 2021
Line 91:		Line 91:
	Install docker using your distro's package manager and then start the service.		Install docker using your distro's package manager and then start the service.

			=== CentOS ===
			{{Highlight
			\| code = # yum install -y yum-utils
			# yum-config-manager \
			--add-repo \
			https://download.docker.com/linux/centos/docker-ce.repo

			# yum install docker-ce docker-ce-cli containerd.io
			\| lang = terminal
			}}

			=== Fedora ===
	On a Fedora distro (https://docs.docker.com/engine/installation/linux/docker-ce/fedora/#install-using-the-repository):		On a Fedora distro (https://docs.docker.com/engine/installation/linux/docker-ce/fedora/#install-using-the-repository):
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
Line 112:		Line 124:
	See more here: https://docs.docker.com/engine/installation/linux/linux-postinstall/		See more here: https://docs.docker.com/engine/installation/linux/linux-postinstall/

	===Fedora 31===		====Fedora 31====
	https://forum.linuxconfig.org/t/how-to-install-docker-on-fedora-31-linuxconfig-org/3605/2		https://forum.linuxconfig.org/t/how-to-install-docker-on-fedora-31-linuxconfig-org/3605/2

Line 571:		Line 583:
	More information found at https://fedoraproject.org/wiki/Common_F31_bugs#Other_software_issues		More information found at https://fedoraproject.org/wiki/Common_F31_bugs#Other_software_issues

	=== Alpine Linux ===		===Alpine Linux===
	After a server crash, docker couldn't start. /var/log/docker.log showed an error related to boltdb <code>panic: invalid page type: 7: 10</code>. This was only fixed by removing <code>/var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db</code> and then restarting docker.		After a server crash, docker couldn't start. /var/log/docker.log showed an error related to boltdb <code>panic: invalid page type: 7: 10</code>. This was only fixed by removing <code>/var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db</code> and then restarting docker.

Leo: alpine linux issues

2021-01-21T16:52:12Z

alpine linux issues

← Older revision		Revision as of 16:52, 21 January 2021
Line 570:		Line 570:

	More information found at https://fedoraproject.org/wiki/Common_F31_bugs#Other_software_issues		More information found at https://fedoraproject.org/wiki/Common_F31_bugs#Other_software_issues

			=== Alpine Linux ===
			After a server crash, docker couldn't start. /var/log/docker.log showed an error related to boltdb <code>panic: invalid page type: 7: 10</code>. This was only fixed by removing <code>/var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db</code> and then restarting docker.

	==Questions & Answers==		==Questions & Answers==

Leo at 21:37, 19 January 2021

2021-01-19T21:37:18Z

← Older revision		Revision as of 21:37, 19 January 2021
Line 34:		Line 34:

	*Version numbers can be given after a colon.		*Version numbers can be given after a colon.
			\|-
			\|<code>docker load</code>
			\|Loads a docker image from file. Eg. <code>docker load -i my_image.tar</code>.
	\|-		\|-
	\|<code>docker run</code>		\|<code>docker run</code>
Line 100:		Line 103:
	}}		}}

	To play with docker, you will need to run things as root or be part of a group that has access to docker's socket.		To play with docker, you will need to run things as root or be part of the docker group that has access to docker's socket. To allow normal users access to docker, add them to the docker group:

			{{Highlight
			\| code = # usermod -aG docker username
			\| lang = terminal
			}}

	See more here: https://docs.docker.com/engine/installation/linux/linux-postinstall/		See more here: https://docs.docker.com/engine/installation/linux/linux-postinstall/
Line 341:		Line 349:
	==Tasks==		==Tasks==

	=== Container accessing a host service ===		===Container accessing a host service===
	To allow the container access to a service that's running on the host., put the container as part of the docker_gwbridge network. Using Docker Compose, this is done by adding the container to the <code>docker_gwbridge</code> network from external.		To allow the container access to a service that's running on the host., put the container as part of the docker_gwbridge network. Using Docker Compose, this is done by adding the container to the <code>docker_gwbridge</code> network from external.
	{{Highlight		{{Highlight

Leo: /* Tasks */

2020-11-14T01:46:43Z

Tasks

← Older revision		Revision as of 01:46, 14 November 2020
Line 324:		Line 324:
	Images can be pushed to a remote registry using <code>docker push</code>.		Images can be pushed to a remote registry using <code>docker push</code>.

	==== Container Image Security ====		====Container Image Security====
	A few things to keep in mind when building container images:		A few things to keep in mind when building container images:

	# Do not store secrets in environment variables defined in a Dockerfile or copied into the container itself. These will be baked into the image when built and anyone with access to the image can retrieve your secrets. Instead, these should be passed in to the container via volumes or as container environment variables.		#Do not store secrets in environment variables defined in a Dockerfile or copied into the container itself. These will be baked into the image when built and anyone with access to the image can retrieve your secrets. Instead, these should be passed in to the container via volumes or as container environment variables.
	# Use a trusted base image pinned to a specific version. If you rely on someone else's base image, you are trusting that the underlying system they provide is clean. Images from Dockerhub without a namespace are considered trustworthy. Pinning a version ensures reliability and repeatability when building.		#Use a trusted base image pinned to a specific version. If you rely on someone else's base image, you are trusting that the underlying system they provide is clean. Images from Dockerhub without a namespace are considered trustworthy. Pinning a version ensures reliability and repeatability when building.
	# Avoid external dependencies. This includes curl bashing (<code>curl remote-server\| bash</code>) or ADDing remote files from the internet during build time. To some extent, this also applies to packages that are installed with package managers during the setup process, but this may be difficult to avoid completely.		#Avoid external dependencies. This includes curl bashing (<code>curl remote-server\| bash</code>) or ADDing remote files from the internet during build time. To some extent, this also applies to packages that are installed with package managers during the setup process, but this may be difficult to avoid completely.
	# While Docker doesn't allow for non-root containers, your container should avoid running as root when possible. Changes that need to be made to the base image should be done during build time and once the container starts, it should only have regular user access to the system. This may cause issues with services that need to bind to lower ports but can be mitigated by having it bind to high port numbers and have the container remap port numbers instead.		#While Docker doesn't allow for non-root containers, your container should avoid running as root when possible. Changes that need to be made to the base image should be done during build time and once the container starts, it should only have regular user access to the system. This may cause issues with services that need to bind to lower ports but can be mitigated by having it bind to high port numbers and have the container remap port numbers instead.

	==Management and Orchestration Tools==		==Management and Orchestration Tools==
Line 340:		Line 340:

	==Tasks==		==Tasks==

			=== Container accessing a host service ===
			To allow the container access to a service that's running on the host., put the container as part of the docker_gwbridge network. Using Docker Compose, this is done by adding the container to the <code>docker_gwbridge</code> network from external.
			{{Highlight
			\| code = grafana:
			image: grafana/grafana
			networks:
			- traefik
			- dockernet

			dockernet:
			external:
			name: docker_gwbridge
			\| lang = text
			}}
			Ensure that the service running on the host is listening on an address from the docker_gwbridge interface.

	===Overriding Entrypoint in <code>docker run</code>===		===Overriding Entrypoint in <code>docker run</code>===

Leo: /* Image Building with Dockerfiles */

2020-10-14T21:19:19Z

Image Building with Dockerfiles

← Older revision		Revision as of 21:19, 14 October 2020
Line 288:		Line 288:

	===Image Building with Dockerfiles===		===Image Building with Dockerfiles===
	A Dockerfile defines the steps required to build a ~~Docker~~ image. ~~Use~~ the ~~<code>docker build</code> command on a directory containing a <code>Dockerfile</code>~~ to ~~build a docker~~ image to the ~~local docker registry~~.		A Docker image contains all the necessary files an application needs to run. Container images can either be built from a blank slate (from scratch) or be built upon another existing image (such as one containing an operating system or application). How such a container image should be built is outlined in a Dockerfile. A Dockerfile defines all the steps required to build a container image. It specifies the base image to use, what steps are needed ontop of this existing image, and any other options such as volumes or exposed network ports that are needed to make the container run appropriately.

	A ~~dockerfile~~ should contain at the very least:		With a Dockerfile created, an image can then be built using the <code>docker build</code> command on a directory containing the <code>Dockerfile</code>. Optionally, a tag which specifies the version of the image can be set and then pushed to a container registry for others to use. A Dockerfile should contain at the very least the base image, some intermediate commands to run to set the application up, and a command that should be executed when the container starts up. For example:{{highlight\|lang=text\|code=
	{{highlight\|lang=text\|code=
	# The base image to use (eg. the operating system, or service)		# The base image to use (eg. the operating system, or service)
	FROM baseimage:version		FROM baseimage:version
Line 324:		Line 323:

	Images can be pushed to a remote registry using <code>docker push</code>.		Images can be pushed to a remote registry using <code>docker push</code>.

			==== Container Image Security ====
			A few things to keep in mind when building container images:

			# Do not store secrets in environment variables defined in a Dockerfile or copied into the container itself. These will be baked into the image when built and anyone with access to the image can retrieve your secrets. Instead, these should be passed in to the container via volumes or as container environment variables.
			# Use a trusted base image pinned to a specific version. If you rely on someone else's base image, you are trusting that the underlying system they provide is clean. Images from Dockerhub without a namespace are considered trustworthy. Pinning a version ensures reliability and repeatability when building.
			# Avoid external dependencies. This includes curl bashing (<code>curl remote-server\| bash</code>) or ADDing remote files from the internet during build time. To some extent, this also applies to packages that are installed with package managers during the setup process, but this may be difficult to avoid completely.
			# While Docker doesn't allow for non-root containers, your container should avoid running as root when possible. Changes that need to be made to the base image should be done during build time and once the container starts, it should only have regular user access to the system. This may cause issues with services that need to bind to lower ports but can be mitigated by having it bind to high port numbers and have the container remap port numbers instead.

	==Management and Orchestration Tools==		==Management and Orchestration Tools==

Leo at 21:02, 14 October 2020

2020-10-14T21:02:56Z

← Older revision		Revision as of 21:02, 14 October 2020
Line 5:		Line 5:
	The surge in popularity with Docker has lead to the increase use in the idea of containerizing applications in general over the past few years. With the rise of orchestration tools such as [[Kubernetes]], containers can now be managed by software. Containers can go up and down depending on load, response times, or hardware availability.		The surge in popularity with Docker has lead to the increase use in the idea of containerizing applications in general over the past few years. With the rise of orchestration tools such as [[Kubernetes]], containers can now be managed by software. Containers can go up and down depending on load, response times, or hardware availability.

	More recently, the Open Container Initiative (OCI) was launched to create an industry standard for container formats and runtimes. The ~~software projects containerd (which manages~~ the container ~~runtime) and runc (~~which ~~containerd calls to run~~ a ~~container) implement this standard~~ and ~~is used by Docker since 1~~.11. Other projects such as [[Podman]] and rkt follow the OCI standard ~~which makes~~ container images portable across different host environments.		More recently, the Open Container Initiative (OCI) was launched to create an industry standard for container formats and runtimes. The Docker engine since version 1.11 began using the OCI compatible container lifecycle management tool called containerd which provides a standardized API for managing, transferring, and starting containers. Containerd uses runc that handles the spawning and running of containers according to the OCI specification. Other projects such as [[Podman]] and rkt follow the OCI standard but utilizing different underlying technologies different from containerd+runc. However, since they all follow the OCI spec, container images remain portable across different host environments.

	==Motivation behind Containers==		==Motivation behind Containers==

Leo at 05:15, 14 October 2020

2020-10-14T05:15:26Z

← Older revision		Revision as of 05:15, 14 October 2020
Line 5:		Line 5:
	The surge in popularity with Docker has lead to the increase use in the idea of containerizing applications in general over the past few years. With the rise of orchestration tools such as [[Kubernetes]], containers can now be managed by software. Containers can go up and down depending on load, response times, or hardware availability.		The surge in popularity with Docker has lead to the increase use in the idea of containerizing applications in general over the past few years. With the rise of orchestration tools such as [[Kubernetes]], containers can now be managed by software. Containers can go up and down depending on load, response times, or hardware availability.

	More recently, the Open Container Initiative (OCI) was launched to create an industry standard for container formats and runtimes. ~~This allowed other initiatives~~ to implement ~~different container runtimes including~~ [[~~runc]~~]~~, [[containerd~~]~~], [[~~rkt~~]], [[podman]], among others~~.		More recently, the Open Container Initiative (OCI) was launched to create an industry standard for container formats and runtimes. The software projects containerd (which manages the container runtime) and runc (which containerd calls to run a container) implement this standard and is used by Docker since 1.11. Other projects such as [[Podman]] and rkt follow the OCI standard which makes container images portable across different host environments.

	==Motivation behind Containers==		==Motivation behind Containers==