Docker Compose Network (How it Works for Developers)

What is Docker?

Docker is an open-source platform that uses container-based concepts to automate the deployment and scaling of applications inside lightweight, portable containers. In simple words, a Docker container puts all the application code and its dependencies together within one unit, consistent across environments-from a developer's laptop to the test server or production cloud servers.

Containers do not behave like traditional virtual machines (VMs) because they share a host system's operating system kernel. Therefore, containers are much more efficient and faster to start. Indeed, Docker containers guarantee consistent behavior across all stages of the development cycle.

In fact, Docker images are templates for descriptions of containers that hold the application environment. This set also includes toolkits for managing container life cycles. One example is Docker Compose, which you can use to orchestrate applications that consist of multiple containers. Then there's Docker Hub, a registry for sharing images.

What is Docker compose networks?

Docker Compose networks allow services running in a Docker Compose application to talk to each other within the same encapsulated environments. If you define more than one service in a docker-compose.yml file, Docker Compose creates a default network automatically so that those services can communicate with each other using service names as hostnames. Essentially allows the user to define their own network and multiple services with the network created.

Default Bridge Network: If you define no network for your containers when you run docker-compose up, Docker automatically creates a bridge network. All containers can communicate with each other with their service name as hostname on this default driver network.

Custom Networks: With these options, users can define one or two custom networks and even more as user-defined networks. You can define custom networks within your container port and docker-compose.yml file. By assigning services to these networks you control how containers may communicate:

• Internal networks isolate services from others.
• Multiple networks allow some services to communicate with one another while denying others such access. Service discovery: Every service gets a hostname equal to its name in the configuration. That is, you can refer to another service in one container by using the name of the other service, e.g. in the web service, you would use db to refer to the IP of the database container.

Network Modes: You can also set network modes to use host, bridge, or none for services. The most often used is a bridge, which isolates container traffic.

What Are Docker Network Drivers?

Docker network drivers describe the connections and communication of the containers with one another and with other containers and systems. There are various use cases, and network drivers can be applied to these cases, each providing a different level of isolation, connectivity, and performance. We'll go through each network driver and explain their usage.

Types of Docker Network Drivers

Bridge (Default)

Internal docker networks allow a container to communicate with others based on a single host. If you launch containers without specifying a network, Docker uses the default bridge network.

docker network create --driver bridge my_bridge_network
docker run -d --name container1 --network my_bridge_network busybox sleep 3600
docker run -d --name container2 --network my_bridge_network busybox sleep 3600

docker network create --driver bridge my_bridge_network
docker run -d --name container1 --network my_bridge_network busybox sleep 3600
docker run -d --name container2 --network my_bridge_network busybox sleep 3600

Here, the service names can be used to communicate, like ping container1 and container2.

Host

With the host driver, the container directly shares the host network stack, so a container does not get its own custom network isolation.

docker run -d --network host nginx

docker run -d --network host nginx

The NGINX container now shares the host's IP and network interfaces, thus bypassing network isolation.

Overlay

It interconnects containers across several hosts and is used mainly in Docker Swarm or Kubernetes environments, connecting physical or virtual machines through containers to communicate securely using a virtual network.

docker network create -d overlay my_overlay_network
docker service create --name web --network my_overlay_network nginx

docker network create -d overlay my_overlay_network
docker service create --name web --network my_overlay_network nginx

This creates a service in a Swarm cluster that can be stretched across multiple Docker hosts.

None:

This none-driver disables networking for the container. This container is isolated from any kind of external network communication.

docker run -d --network none busybox sleep 3600

docker run -d --network none busybox sleep 3600

The busy box container will not have access to the internet and will not be able to send out calls to other containers' in own networks or the outside world.

Macvlan

The Macvlan driver enables containers to appear as physical devices in the network with their own MAC addresses, so they can directly access the physical network.

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 macvlan_network
docker run -d --network macvlan_network busybox sleep 3600

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 macvlan_network
docker run -d --network macvlan_network busybox sleep 3600

IPvlan

The IPvlan driver is similar to Macvlan but focuses on assigning IP addresses instead of relying on Layer 2 (MAC addresses). It allows multiple containers to share the same network interface.

docker network create -d ipvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 ipvlan_network
docker run -d --network ipvlan_network busybox sleep 3600

docker network create -d ipvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 ipvlan_network
docker run -d --network ipvlan_network busybox sleep 3600

It will share the host's Layer 2 Ethernet interface with my network but have a different IP address.

Custom Plugins

Docker's custom plugins are third-party or user-developed network drivers offering elaborate features on network capabilities that are more than what Docker may offer as a default. Third-party Docker plugins external networking solution frameworks allow Docker containers to access and tie into some well-known frameworks like Software-Defined Networking, thereby improving the developers' capabilities such as security, scalability as well as multi-host networking. Docker provides developers and vendors with a versatile architecture for network plugins, allowing them to install and use Docker in the same way as the native driver.

IronSecureDoc

IronSecureDoc for Docker makes it easy for developers to add secure document processing capabilities to their containerized applications. With Docker, you can encapsulate your ASP.NET Core application with IronSecureDoc in a uniform environment that eases deployment and scaling. To get it running, you build a Dockerfile that composes your ASP.NET Core application using the IronSecureDoc library and possibly other installation scripts or configurations necessary to get things working.

It also includes a docker-compose.yml file comprising service dependencies, environment variables, and mapped ports, thereby providing access to this. Therefore, the tasks involved with the security of documents make it easier to manage so that your web application will run efficiently and effectively outside the one used in development or production. Installing and Configuring IronSecureDoc as it is in the case of Docker, the proper installation and configuration of IronSecureDoc shall be necessary to seize all the capabilities offered by encrypting the documents, redaction, etc.

Install and Running IronsecureDoc

Run the following command at the Command Prompt or in an open terminal window so the IronSecureDoc Docker image is fetched from the repository.

docker pull ironsoftwareofficial/ironsecuredoc

docker pull ironsoftwareofficial/ironsecuredoc

After pulling an image from a Docker container, we can use another command to start up IronSecureDoc, another operating container.

docker container run --rm -p 8080:8080 -e IronSecureDoc_LicenseKey=<IRONSECUREDOC_LICENSE_KEY> -e ENVIRONMENT=Development -e HTTP_PORTS=8080 ironsoftwareofficial/ironsecuredoc:latest

docker container run --rm -p 8080:8080 -e IronSecureDoc_LicenseKey=<IRONSECUREDOC_LICENSE_KEY> -e ENVIRONMENT=Development -e HTTP_PORTS=8080 ironsoftwareofficial/ironsecuredoc:latest

The Docker run command above will bring up a container instance of the IronSecureDoc. The bridge network is assumed for network isolation. This also enables external access to services exposed inside the container through http://localhost:8080 by using the flag —p 8080:8080; this exposes the internal service, running on port 8080 of the container's network, on its own network, at port 8080 of the host's existing network.

Containers are, by default, running on Docker's bridge network, so they isolate themselves from other containers and the outside world unless you expose them using port mapping, which you do here. The environment variables being passed on IronSecureDoc_LicenseKey, ENVIRONMENT, HTTP_PORTS -configure the application's behavior in the container. This flag causes the container to be removed when it stops.

This setup has the advantage that the bridge network isolates the container connect services internally whereas the port mapping bridges out external traffic from the host machine into the container's service thus making access easy.

Using IronSecuredoc with Docker Network Port

IronSecureDoc's REST API allows users to redact, certify, and encrypt documents upon installation and launch in Docker; it has also been mentioned elsewhere. Here is the link to the documentation.

For example, to submit a document for encryption, you can perform POST to the IronSecureDoc API:

curl -X 'POST' \
  'http://localhost:8080/v1/document-services/pdfs/encrypt?user_password=demo' \
  -H 'accept: */*' \
  -H 'Content-Type: multipart/form-data' \
  -F 'pdf_file=@test.pdf;type=application/pdf'

curl -X 'POST' \
  'http://localhost:8080/v1/document-services/pdfs/encrypt?user_password=demo' \
  -H 'accept: */*' \
  -H 'Content-Type: multipart/form-data' \
  -F 'pdf_file=@test.pdf;type=application/pdf'

This will automatically send the document over to IronSecureDoc, where it will be appropriately encrypted.

Conclusion

Generally, Docker networking is important in controlling application applications and their interaction with other applications and the rest of the world through different drivers and configurations of diverse application needs. The default bridge network configuration allows one to reach very basic isolation as the service can be exposed to host systems through port mapping, as in the case of the IronSecureDoc application. It facilitates easier management and configuration of containerized applications because that enhances the operational flexibility and scalability of the application.

IronSecureDoc, an advanced document processing tool, is always ready to use Docker's capabilities in terms of containerization. That means rolling out apps with speed and reliability, guarantees support for multiple environments while environmental application support is even in nature. It integrates Docker networking with IronSecureDoc, wherein the integration of applications is easy, accessible, and managed.

Hence, it streamlines workflows much better to improve efficiency and results in operations when processing documents. This will ultimately enhance the experience both in developing and deploying it, thus making it a valuable solution for modern software applications. For more information on Ironsecuredoc licensing, please follow this page. To learn more about many of the product offerings from Iron Software, follow this link.