Mehrere Container ausführen

Verwenden Sie Docker Compose, um mehrere Container über eine YAML-Datei zu definieren und dauerhaft zu starten, statt einzelne Docker-Befehle auszuführen. Dieses Thema demonstriert die Orchestrierung eines WinCC OA-Servers mit lokalen und Cloud-basierten PostgreSQL-Diensten sowie einem DMZ-Webserver, die Konfiguration von Images, Volumes, Netzwerken, Ports und Umgebungsvariablen sowie die Verwaltung des Lebenszyklus mit Compose-Befehlen (up/down, build, detach, force-recreate) und den erforderlichen Volume-Berechtigungen.

Video Information

Length
10:26
Language
English

Transcript

Welcome back. Now let's find out how to manage the start of multiple containers. The Docker command is a flexible foundational tool.

However, if you want to run multiple containers and ensure that the run commands or configurations are persistent, it's better to use Docker Compose. Docker Compose uses a YAML file to define multiple aspects such as build instructions, container configurations, volumes, and network settings.

For example, instead of running the demo application as command, we can create a docker compose YAML file with the same options. This defines the service demo, our Docker container with image, volumes, environment parameters, and network settings.

To start the service, we need to run the command docker compose -F and the YAML file name with option up for starting. Other options are down for
  • stopping,
  • build to create an image,
  • -D for detach mode and
  • the service name if you want to react on a dedicated service defined in the file.

First, switch to the directory containing the YAML file. Then start the container defined in it.

With shortcut control + c we can stop the container. To start in detach mode the option D is used and with down it can be stopped. The up command will reuse the image and last container if there was no change since last run. With the option force recreate you can force to get a new container.

Let us now set up a small scenario starting from a standalone application. First we want to bring this in a docker. Then the usage of a standard Postgre image and an addition Postgre posters container which could be in the cloud should be added.

For access restriction we create a remote webserver in a DMZ. So this could be the target architecture for easy handling. I share my project via volume. Use a WinCC OA server image, a smaller remote image and twice the standard posters image.

The cloud one have its own data volume for the database. Because I have created my WinCC OA project under windows, I cannot use my posters database in docker because this is not compatible.

Let's remove the local Postgre folder which will be recreated by our NGA. To run the application docker example_ed in a single container, we create the YAML file defining the service name WinCC OA build and image information using our license server and running our project mounted via volume to allow a remote GEDI- PARA connection for my host and web UI connection via browser.

We specify the ports, start the docker compose and let's connect to the application via web UI. We start a simple simulation and have a look. Postgre backend has been connected successfully.

As next task, let's move the Postgre service which runs currently on the WinCC OA server to a separate standard Postgre 16 container. Let's stop the database, deactivate the auto start and change location setting to Postgre server instead of local host.

  • First database connection host is Postgre, the name of our service using the standard port 15432.
  • Then disable automatic startup.
  • Third, stop any running containers.
  • Fourth, in the YAML file, define the Postgre service using the Postgre 16 image. Mount the project's Postgre data folder as a volume and set the PG data environment variable accordingly.

    Finally, start docker compose using the remote Postgre instance. On startup of the Postgre container, we see that it does not have the sufficient user permission for our volume.

    So we must grant the permission. Therefore, we log in into Postgre container to read the user ID of the poster user and change the owner of the database folder to the Postgre user ID.

    Our remote Postgre is running. Now let's add another central Postgre instance.

    This could be located somewhere else for example in the cloud. We create a new service Postgre could and define a dedicated volume. We start the new Postgre cloud container via docker compose up starting a bash for the WinCC OA container end. Use the SQL interface to import the WinCC OA scheme into our simulated Postgre cloud database.

    Now we want to use our new archive. Therefore let's start a remote PARA or gate. In the config file, we have defined the local network adapter and on starting the container, we have shared the ports for data and event manager connection.

    Now create a new database backend connection for the cloud posters. The profile has to be poss 5432. User is ETM and password ETM123. Execution file for the backend is Postgre and db.database is WinCC OA.

    Deactivate automatic management and activate the connection. Create a new archive group. Use the new archive group to archive our values. Start a remote PARA to configure the new archive group on the simulated data point elements.

    We are configuring it on the master data point and apply it to all instances.

    Let's start the value simulation which will result in archive data being stored in both Postgre instances.

    If we deactivate the archive connection to PostgreSQL, we will only see historical data from our cloud Postgre instance. This means we will miss the previously simulated values that were generated before the cloud database was operational.

    Once we reactivate the PostgreSQL archive connection, historical values from both instances will become available Yeah. For security reasons, we want to deploy a dedicated web server in the DMZ. To achieve this, we can run a lightweight remote manager container that acts as a secure interface between external clients and the internal system.

    The remote web server configuration will be done in progs and config file which needs to be mounted via volume to the remote manager container.

    To make it easy for deployment, I will create separated config and log folders for this container in our project folder. We will mount them with different name into the container and share the data folder via volume.

    Since the rest of the project is not needed in this container, we can use an empty project folder structure. Here are the changes to be done.

    The config file defines the data and event host of the WinCC OA server. So between the docker container, it is the service name WinCC OA as defined in the compose file.

    The progs file defines to start only the web server and dashboard managers.

    We use the project folder structure of an empty project and mount the config data and log folder into the new container. We will stop the dashboard server and move it to the web server progs file.

    In docker compose yaml file we add the service web server mounting an own config and log folder and the data folder via volume.

    And we map the websocket server ports from 8,000s to 9,000s to clearly separate them from the other web server.

    In the web server config file, the data and event host needs to be defined. In addition, the progs files need to be updated.

    Stopping and setting the dashboard script on the main server to manual start. Adding automatic starting dashboard and web client scripts on the DMZ web server.

    Restarting the Docker Compose and connect the browser to the DMZ web server UI via HTTPS port 9843. Finally, our example architecture has been built.