docker-containers | A collection of pedantic docker containers | Continuous Deployment library

When you create a container, it is possible to assign it the network stack of another container. This allows the two containers to communicate via the loopback interface (localhost, that is). Though I'm not sure if it works on Mac. Try with the commands below.

Start an NGINX container that will listen on port 80:

The whole CPU/Memory Limitation stuff is using cgroups. You can find all settings performed by docker run (either per args or per default) under /sys/fs/cgroup/memory/docker/ for memory or /sys/fs/cgroup/cpu/docker/ for cpu.

So the --kernel-memory:

Reading: cat memory.kmem.limit_in_bytes

Writing: sudo -s echo 2167483648 > memory.kmem.limit_in_bytes

And also the benchmarking memory.kmem.max_usage_in_bytes and memory.kmem.usage_in_bytes which shows (rather selfexplaining) the current usage and the highest usage overall.

For the functionality I will recommend reading Kernel Docs for CGroups V1 instead of the docker docs:

2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)

With the Kernel memory extension, the Memory Controller is able to limit the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it possible to DoS the system by consuming too much of this precious resource. [..]

The memory used is accumulated into memory.kmem.usage_in_bytes, or in a separate counter when it makes sense. (currently only for tcp). The main "kmem" counter is fed into the main counter, so kmem charges will also be visible from the user counter.

Currently no soft limit is implemented for kernel memory. It is future work to trigger slab reclaim when those limits are reached.

and

2.7.2 Common use cases

Because the "kmem" counter is fed to the main user counter, kernel memory can never be limited completely independently of user memory. Say "U" is the user limit, and "K" the kernel limit. There are three possible ways limits can be set:

The problem was that I wasn't running the script asynchronous, and bash was waiting to end the tail command at the end of install.sh (which was "endless"), here is the part of the code that was changed:

For communicating between multiple docker-compose clients, you need to make sure that the containers you want to talk to each other are on the same network.

For example, (edited for brevity) here you have one of the docker-compose.yml

Your Angular frontend application will not be run in the same machine where your server will be running. Basically, your frontend application will be shipped to the client browser (through Nginx, for example), and then it will need to communicate with the server (backend application) through a connection.

you will have to make your API calls using your server IP address (or domain name), and of course, you need to expose your backend application inside your server and publish it on the correct port.

The reason the files are not being found is due to how docker's context works. Since you're running docker build from the root, your context will be within the root as opposed to from the path for your dockerfile. That means that your docker build command is trying to find /requirements.txt instead of src/app/requirements.txt. You can fix this relatively easily by just executing a cd to change to your /src/app directory before you run docker build, and removing the -f flag from your docker build (since you no longer need to specify the folder).

Since each job executes in an isolated container, you don't need to worry about CDing back to your build root, since your job never runs any other non-docker commands.

Compose has the notion of a project name. Compose sets a label on the container it creates with the project name, and uses this to find containers later. More visibly, the project name is also part of the default container, network, and volume names; if you docker network ls and see somename_default, that embeds the project name.

The default project name is the basename of the current directory, but you can set a COMPOSE_PROJECT_NAME environment variable to override it. In your example, you're running /tmp/docker-compose.yml so the default project name is tmp, but that doesn't match what you've run from the host. You can manually set this environment variable when you launch the container:

In a multistage build, only the last FROM will be used to generate final image.

E.g., for next example, the a.txt only could be seen in the first stage, can't be seen in the final image.

Dockerfile:

The solution I found is to add RUN go build -o worker /path/to/main.go in my dockerfile and then to start the docker container with ./worker --arg1 --arg2 instead of go run /path/to/main.go --arg1 --arg2.

Doing it this way ensures there aren't any subprocess spawns by go and that ensures signals are handled properly within the docker container.