AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fabf9239e0
qt5base-lts/tests/testserver/docker-compose-for-windows.yml

114 lines
4.0 KiB
YAML
Raw Normal View History

Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
version: '3.4'
# The tag of images is used by docker compose file to launch the corresponding
# docker containers. The value of tag comes from the provisioning script
# (coin/provisioning/.../testserver/docker_testserver.sh). The script gets SHA-1
# of each server context as the tag of docker images. If one of the server
# contexts gets changes, please make sure to update this compose file as well.
# You can run command 'docker images' to list all the tags of test server images.
# For example:
# REPOSITORY TAG
# qt-test-server-apache2 537fe302f61851d1663f41495230d8e3554a4a13
services:
apache2:
container_name: qt-test-server-apache2
domainname: ${TEST_DOMAIN}
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
build:
context: .
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
dockerfile: ${SHARED_DATA}/Dockerfile
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
args:
provisioningImage: qt-test-server-apache2:537fe302f61851d1663f41495230d8e3554a4a13
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
shareDir: ./common
serviceDir: ./apache2
test_domain: ${TEST_DOMAIN}
entrypoint: service/startup.sh
command: [service/ssl.sh, service/apache2.sh]
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
network_mode: "host"
extra_hosts:
- "qt-test-server.${TEST_DOMAIN}:${MACHINE_IP}"
environment:
Select single-name SSL certificate for test servers using host network On Windows and macOS, the containers are deployed into a virtual machine using the host network. All the containers share the same hostname (qt-test-server), and they are connected to the same network domain (local). When running test in such platforms, use the single-name SSL certificate (qt-test-server.local) for SSL related tests. Change-Id: Idf33e01e8dd8814510d848b87b59b5fc0edc903e Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
2019-01-25 21:48:29 +00:00
- test_cert="qt-test-server-host-network-cacert.pem"
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
squid:
container_name: qt-test-server-squid
domainname: ${TEST_DOMAIN}
depends_on:
- apache2
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
build:
context: .
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
dockerfile: ${SHARED_DATA}/Dockerfile
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
args:
provisioningImage: qt-test-server-squid:9c32f41b19aca3d778733c4d8fb0ecc5955e893c
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
shareDir: ./common
serviceDir: ./squid
test_domain: ${TEST_DOMAIN}
entrypoint: service/startup.sh
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
command: service/squid.sh
network_mode: "host"
extra_hosts:
- "qt-test-server.${TEST_DOMAIN}:${MACHINE_IP}"
vsftpd:
container_name: qt-test-server-vsftpd
domainname: ${TEST_DOMAIN}
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
build:
context: .
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
dockerfile: ${SHARED_DATA}/Dockerfile
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
args:
provisioningImage: qt-test-server-vsftpd:f3a9c8d793a77cc007c0e4e481bec01f9e3eeb7e
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
shareDir: ./common
serviceDir: ./vsftpd
test_domain: ${TEST_DOMAIN}
entrypoint: service/startup.sh
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
command: service/vsftpd.sh
network_mode: "host"
extra_hosts:
- "qt-test-server.${TEST_DOMAIN}:${MACHINE_IP}"
ftp-proxy:
container_name: qt-test-server-ftp-proxy
domainname: ${TEST_DOMAIN}
depends_on:
- vsftpd
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
build:
context: .
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
dockerfile: ${SHARED_DATA}/Dockerfile
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
args:
provisioningImage: qt-test-server-ftp-proxy:d7de8b28392d173db512a558ccc84ead8bece2ae
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
shareDir: ./common
serviceDir: ./ftp-proxy
test_domain: ${TEST_DOMAIN}
entrypoint: service/startup.sh
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
command: service/ftp-proxy.sh
network_mode: "host"
extra_hosts:
- "qt-test-server.${TEST_DOMAIN}:${MACHINE_IP}"
danted:
container_name: qt-test-server-danted
domainname: ${TEST_DOMAIN}
depends_on:
- apache2
- vsftpd
- ftp-proxy
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
build:
context: .
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
dockerfile: ${SHARED_DATA}/Dockerfile
Add image layer on windows The docker-compose files were trying to use volume sharing, which is not supported on Windows in conjunction with docker-machine. Hence create a separate layer on Windows, which copies the configuration files to the target. Change-Id: Ifeacc56198ffc8fb2eb31c14ab91334e22e916f5 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-02-06 12:12:35 +00:00
args:
provisioningImage: qt-test-server-danted:35607f9b790524cf9690c7d12a9a401696b7b6b5
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
shareDir: ./common
serviceDir: ./danted
test_domain: ${TEST_DOMAIN}
entrypoint: service/startup.sh
Docker-based test servers for network-related Qt autotests on Windows There is no docker bridge on Windows. Docker document recommends using port mapping to connect to a container. The problem is that it causes a port conflict if the user is running a service that binds the same port on the host. This change applies the same solution of macOS to deploy the docker environment into VirtualBox and use the host network option. Task-number: QTQAINFRA-2294 Change-Id: Iedcb8daa39373f02adb59f02eae2775f02870c54 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2018-11-27 21:04:02 +00:00
command: service/danted.sh
network_mode: "host"
extra_hosts:
- "qt-test-server.${TEST_DOMAIN}:${MACHINE_IP}"
environment:
Remove useless fall-back network interface of Dante-server Setting the fall-back network interface of danted's environment to eth0 by docker-compose file is redundant because the value of danted's configuration (danted.conf) has been set to eth0 by default. Change-Id: If2dea8daaf851577a573e201e9c50684916e5206 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
2019-01-18 23:11:54 +00:00
- danted_internal=${MACHINE_IP}
- danted_external=${MACHINE_IP}
- danted_auth_internal=${MACHINE_IP}
- danted_auth_external=${MACHINE_IP}
Support multi-stage builds to provision the configurations and test data In order to reuse the test server to the external modules, it is much easier to share the common configurations (scripts) and test data via Dockerfile. In addition, the external module can create more layers depending on their needs. Therefore, supporting multi-stage builds is needed. The disadvantage is that the docker-compose needs to re-build the images every time. However, it is just a one-time effort. If the Dockerfile doesn't get changed, the extra build time can be ignored. Because of multi-stage builds, the test server will keep a Dockerfile at least. Therefore, the volume sharing is no more needed. The test data of a service can be added into the images by using COPY/ADD commands. NOTE: This patch relies on docker-compose v1.21.0 (docker-compose build now supports the use of Dockerfile from outside the build context). Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-03-22 15:20:52 +00:00
Reference in New Issue Copy Permalink