Shulou(Shulou.com)06/02 Report--

Preface

When we deploy the application to the server as a Docker container, we usually need to consider two aspects: network and storage.

In terms of network, some applications need to occupy ports, and some of them even need to provide access.

For security reasons, proxy forwarding is more appropriate than directly opening firewall ports.

In terms of storage, because the interior of the container is not suitable for data persistence, the data is generally stored on the server disk by mounting the volume.

But the server can not guarantee absolute security, so the data also needs to be backed up to the cloud.

Proxy forwarding

By default, the networks of containers are isolated from each other, but for some related applications (web front-end containers, server containers and database containers), they are generally divided into an independent bridging subnet (hereinafter referred to as subnets), so that these containers can communicate with each other, but at the same time be isolated from the outside.

For containers that need to provide access outside the subnet, you can map the port to the server host. The whole structure is roughly as follows:

The above port mapping only solves the problem of the server (host) accessing the container network service. If we want to access the container on the server through the Internet from the local machine, it is generally not possible, because except for security considerations, the server will enable the firewall by default and only open a few ports such as 22.

For traditional network processes, this is achieved by forwarding network requests through a reverse proxy server, such as using Nginx to configure the following proxies:

# forward server {listen 80; server_name www.xx.com; location / a {proxy_pass localhost:1234;} location / b {proxy_pass localhost:2234;}} # forward server {listen 80; server_name www.yy.com; location / {proxy_pass localhost:1234;}} for different domain names

So the problem seems to be solved at this point, but what if Nginx is also running in a container?

We just mentioned that subnets are isolated from external containers, so Nginx containers will not be able to access these external services.

You may not want to think of dividing the Nginx container into corresponding subnetworks. The container does support the configuration of multiple subnets, but the trouble with this method is that you need to modify the network configuration of the Nginx container and restart the container each time you add a subnet.

So a better way is to set Nginx to HOST network mode. Give up the isolation of the Nginx container from the server and share the network and port directly with the server. Then the Nginx container can directly access all containers with mapped ports.

As shown in the following figure:

Data backup

Application scenario

Considering the speed and security issues, companies usually have some servers that are only accessible by the intranet. But the data on these servers, including the server itself, may be modified or malfunctioned at any time.

So data backup is particularly important. Here we talk about smaller data backups.

Take the knowledge base server I recently built for the team as an example.

The web application is a small python service, which is deployed on the intranet server in the form of a container, supports online editing and saves data in the form of md files.

Because in the event of a container failure, the internal data can no longer be accessed, so it is definitely not safe to put it directly in the container. You can only let the container and the server share data by mounting files.

So how to back up the data? Here we choose GitHub's private repository for preservation. There are three reasons:

It's clear. Data is not easy to lose and steal. Convenient, you only need to use the git command to back up. fast. Because the volume and quantity of data backed up is not large.

Although the method has been determined, there are still two problems with implementation:

Permission authentication is required to the GitHub warehouse. How to regularly or automatically submit data to GitHub.

Realization method

First of all, according to the principle of container single blame, we should create a new container to perform backup tasks.

Here I can use docker-compose or other orchestration tools to create multiple containers.

Then there is permission authentication, which creates a ssh key locally and adds it to the GitHub settings, so that the container can push files to the corresponding repository.

But now only the server can push the code, and the container doesn't work yet, so you still need to copy the .ssh file into the container.

The last is the implementation of automatic backup, the better way is to submit and push the code every time the file changes, but at present there is no simple way to monitor the file in the container, so the second best choice is to adopt the strategy of scheduled task, that is, to execute the corresponding git command every 5 minutes to submit and push the file to the warehouse.

Here you can use a lightweight container based on mirror busybox encapsulation, mount the project code into the container to ensure that the files are updated synchronously, and then start the cron service to implement the operation.

Summary

The above is the whole content of this article, I hope that the content of this article has a certain reference and learning value for your study or work, if you have any questions, you can leave a message and exchange, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.