Docker Community Forums

Share and learn in the Docker community.

How to handle no documentation of containers?

I’m kinda new to Docker and I have issues understanding the use of certain containers in the hub.

Initially I thought I could just pull the container and run it so I have the exact same setup like the creator. But there seems to be other things you have to consider before running it.

Currently I’m trying to setup the following container https://hub.docker.com/r/wonderfall/rtorrent-flood .
It’s the most popular flood container but there is little to no documentation. I don’t want to ask for help to get this container up and running, I rather want to know how I can find out how to setup such a container.

After running the container I can access its web interface. The web interface tells me its unable to connect to rtorrent but rtorrent itself is running inside the container. It seems like I have to set something inside the container or start it with a different parameter, but nothing like this seems to be mentioned in the container. After refreshing I can’t login because the “Connection could not be verified.” leaving this application completely unusable.

I have no idea whether this container is just bad or whether I just oversee something. There are so many different articles about those subjects but all of them use different kind of interfaces for Docker so it’s very hard to understand what’s the “right way” is.

My current approach would be to go through the manual install process of rtorrent and flood to see how they are being setup. But that would kinda destroy the purpose of Docker wouldn’t it?

So I would like to know how you guys are handling such issues. How would you install rtorrent-flood?

At least some environment variables are documented and there is a Dockerfile; that’s much better than with many other images. And there’s a warning “Be aware this image was made for my own use.”. Now there are only 2 ways to get it running, either you ask the author for help or you find out what the Dockerfile and run.sh are doing.

For more information about cgroups and memory in general, see the documentation for Memory Resource Controller.

–memory-swap details
–memory-swap is a modifier flag that only has meaning if --memory is also set. Using swap allows the container to write excess memory requirements to disk when the container has exhausted all the RAM that is available to it. There is a performance penalty for applications that swap memory to disk often.

Its setting can have complicated effects:

If --memory-swap is set to a positive integer, then both --memory and --memory-swap must be set. --memory-swap represents the total amount of memory and swap that can be used, and --memory controls the amount used by non-swap memory. So if --memory=“300m” and --memory-swap=“1g”, the container can use 300m of memory and 700m (1g - 300m) swap.

If --memory-swap is set to 0, the setting is ignored, and the value is treated as unset.

If --memory-swap is set to the same value as --memory, and --memory is set to a positive integer, the container does not have access to swap. See Prevent a container from using swap.

If --memory-swap is unset, and --memory is set, the container can use as much swap as the --memory setting, if the host container has swap memory configured. For instance, if --memory=“300m” and --memory-swap is not set, the container can use 600m in total of memory and swap.

If --memory-swap is explicitly set to -1, the container is allowed to use unlimited swap, up to the amount available on the host system.

Inside the container, tools like free report the host’s available swap, not what’s available inside the container. Don’t rely on the output of free or similar tools to determine whether swap is present.

PREVENT A CONTAINER FROM USING SWAP
If --memory and --memory-swap are set to the same value, this prevents containers from using any swap. This is because --memory-swap is the amount of combined memory and swap that can be used, while --memory is only the amount of physical memory that can be used.

–memory-swappiness details
A value of 0 turns off anonymous page swapping.
A value of 100 sets all anonymous pages as swappable.
By default, if you do not set --memory-swappiness, the value is inherited from the host machine.
–kernel-memory details
Kernel memory limits are expressed in terms of the overall memory allocated to a container. Consider the following scenarios:

Unlimited memory, unlimited kernel memory: This is the default behavior.
Unlimited memory, limited kernel memory: This is appropriate when the amount of memory needed by all cgroups is greater than the amount of memory that actually exists on the host machine. You can configure the kernel memory to never go over what is available on the host machine, and containers which need more memory need to wait for it.
Limited memory, unlimited kernel memory: The overall memory is limited, but the kernel memory is not.
Limited memory, limited kernel memory: Limiting both user and kernel memory can be useful for debugging memory-related problems. If a container is using an unexpected amount of either type of memory, it runs out of memory without affecting other containers or the host machine. Within this setting, if the kernel memory limit is lower than the user memory limit, running out of kernel memory causes the container to experience an OOM error. If the kernel memory limit is higher than the user memory limit, the kernel limit does not cause the container to experience an OOM.
When you turn on any kernel memory limits, the host machine tracks “high water mark” statistics on a per-process basis, so you can track which processes (in this case, containers) are using excess memory. This can be seen per process by viewing /proc//status on the host machine.