How to Deploy a Self-Building Docker Image to Make Changes to Itself in Respect to the Local Environment

How to deploy a Docker image to make changes in the local environment?

So, I think you may have largely missed the point behind Docker, which is the management of containers that are intentionally isolated from your local environment. The idea is that you create containerized applications that can be run on any Docker host without needing to worry about the particular OS installed or configuration of the host machine.

That said, there are a variety of ways to break this isolation if that's really what you want to do.

You can start a container with --net=host (and probably --privileged) if you want to be able to modify the host network configuration (including interface addresses, routing tables, iptables rules, etc).

You can parts of (or all of) the host filesystem as volumes inside the container using the -v command line option. For example, docker run -v /:/host ... would expose the root of your host filesystem as /host inside the container.

Normally, Docker containers have their own PID namespace, which means that processes on the host are not visible inside the container. You can run a container in the host PID namespace by using --pid=host.

You can combine these various options to provide as much or as little access to the host as you need to accomplish your particular task.

If all you're trying to do is install packages on the host, a container is probably the wrong tool for the job.

How to automatically update your docker containers, if base-images are updated

One of the ways to do it is to drive this through your CI/CD systems. Once your parent image is built, have something that scans your git repos for images using that parent. If found, you'd then send a pull request to bump to new versions of the image. The pull request, if all tests pass, would be merged and you'd have a new child image based on updated parent. An example of a tool that takes this approach can be found here: https://engineering.salesforce.com/open-sourcing-dockerfile-image-update-6400121c1a75 .

If you don't control your parent image, as would be the case if you are depending on the official ubuntu image, you can write some tooling that detects changes in the parent image tag or checksum(not the same thing, tags are mutable) and invoke children image builds accordingly.

docker: build requires 1 argument. See 'docker build --help'

You need to add a dot, which means to use the Dockerfile in the local directory.

For example:

docker build -t mytag .

It means you use the Dockerfile in the local directory, and if you use docker 1.5 you can specify a Dockerfile elsewhere. Extract from the help output from docker build:

-f, --file="" Name of the Dockerfile(Default is 'Dockerfile' at context root)

Rebuilding containers when needed

The answer is, as for many other docker-related issues, to ditch docker and switch to buildah. Both the buildah bud, which is drop-in replacement for docker build, and the buildah commit, which is for scripting the build by other means, have a --timestamp option that forces both the timestamp written to the manifest and the timestamps of files in the new layers to specified value. That seems to be the only nondeterminism from the tool itself; standard deterministic build techniques still need to be applied to the build of the application itself, but that's obviously out of buildah scope.

Docker error: invalid reference format: repository name must be lowercase

A "reference" in docker is a pointer to an image. It may be an image name, an image ID, include a registry server in the name, use a sha256 tag to pin the image, and anything else that can be used to point to the image you want to run.

The invalid reference format error message means docker cannot convert the string you've provided to an image. This may be an invalid name, or it may be from a parsing error earlier in the docker run command line if that's how you run the image.

If the name itself is invalid, the repository name must be lowercase means you use upper case characters in your registry or repository name, e.g. YourImageName:latest should be yourimagename:latest.

With the docker run command line, this is often the result in not quoting parameters with spaces, missing the value for an argument, and mistaking the order of the command line. The command line is ordered as:

docker ${args_to_docker} run ${args_to_run} image_ref ${cmd_to_exec}

The most common error in passing args to the run is a volume mapping expanding a path name that includes a space in it, and not quoting the path or escaping the space. E.g.

docker run -v $(pwd):/data image_ref

Where if you're in the directory /home/user/Some Project Dir, that would define an anonymous volume /home/user/Some in your container, and try to run Project:latest with the command Dir:/data image_ref. And the fix is to quote the argument:

docker run -v "$(pwd):/data" image_ref

Other common places to miss quoting include environment variables:

docker run -e SOME_VAR=Value With Spaces image_ref

which docker would interpret as trying to run the image With:latest and the command Spaces image_ref. Again, the fix is to quote the environment parameter:

docker run -e "SOME_VAR=Value With Spaces" image_ref

With a compose file, if you expand a variable in the image name, that variable may not be expanding correctly. So if you have:

version: 2
services:
  app:
    image: ${your_image_name}

Then double check that your_image_name is defined to an all lower case string.

Is it possible to pause a Docker image build?

Is it possible to pause a Docker image

no, you cannot pause the docker build command.

You could give a try to the Scroll Lock key, but depending on your terminal that might fail.

You could pipe the result of the docker build command to less -R:

docker build -t test . | less -R

Once built, you can then use the arrow keys to go up and down, use / to search for test, etc.

-R is to keep colors

-r  -R  ....  --raw-control-chars  --RAW-CONTROL-
                Output "raw" control characters.

Also you can record the output to a file (I know you explicitly said you don't want this solution, but it can suit others):

docker build -t test . | tee build.log