Internal infrastructure with docker

Question

I have a small company network with the following services/servers:

• Jenkins
• Stash (Atlassian)
• Confluence (Atlassian)
• LDAP
• Owncloud
• zabbix (monitoring)
• puppet
• and some Java web apps

all running in separate kvm(libvirt)-vms in separate virtual-subnets on 2 machines (1 internal, 1 hetzner-rootserver) with shorewall inbetween. I'm thinking about switching to Docker.

But I have two questions:

• How can I achieve network security between docker containers (ie I want to prevent owncloud to access any host in the network except ldap-hosts-sslport)
• Just by using docker-linking? If yes: does docker really allow to access only linked containers, but no others?
• By using kubernetes?
• By adding multiple bridging-network-interfaces for each container?
• Would you switch all my infra-services/-servers to docker, or a hybrid solution with just the owncloud and the java-web-apps on docker?

Answer 1

Regarding the multi-host networking: you're right that Docker links won't work across hosts. With Docker 1.9+ you can use "Docker Networking" like described in their blog posthttp://blog.docker.com/2015/11/docker-multi-host-networking-ga/

They don't explain how to secure the connections, though. I strongly suggest to enable TLS on your Docker daemons, which should also secure your multi-host network (that's an assumption, I haven't tried).

With Kubernetes you're going to add another layer of abstraction, so that you'll need to learn working with the pods and services concept. That's fine, but might be a bit too much. Keep in mind that you can still decide to use Kubernetes (or alternatives) later, so the first step should be to learn how you can wrap your services in Docker containers.

You won't necessarily have to switch everything to Docker. You should start with Jenkins, the Java apps, or OwnCloud and then get a bit more used to the Docker universe. Jenkins and OwnCloud will give you enough challenges to gain some experience in maintaining containers. Then you can evaluate much better if Docker makes sense in your setup and with your needs to be applied to the other services.

I personally tend to wrap everything in Docker, but only due to one reason: keeping the host clean. If you get to the point where everything runs in Docker you'll have much more freedom to choose where a service can run and you can move containers to other hosts much more easily.

You should also explore the Docker Hub, where you can find ready to run solutions, eg Atlassian Stash: https://hub.docker.com/r/atlassian/stash/

If you need inspiration for special applications and how to wrap them in Docker, I recommend to have a look in https://github.com/jfrazelle/dockerfiles - you'll find a bunch of good examples there.

Answer 2

You can give containers their own IP from your subnet by creating a network like so:

docker network create \
  --driver=bridge \
  --subnet=135.181.x.y/28 \
  --gateway=135.181.x.y+1 \
  network

Your gateway is the IP of your subnet + 1 so if my subnet was 123.123.123.123 then my gateway should be 123.123.123.124

Unfortunately I have not yet figured out how to make the containers appear to the public from their own ip, at the moment they appear as the dedicated servers' ip. Let me know if you know how I can fix that. I am able to access the container using its ip though.