Table of Contents
This project provides tools that support the deployment of Globus Connect Server using Docker. It serves as a starting point for endpoint administrators interested in containerized deployment for production or testing purposes. Docker knowledge is assumed since this is an early release and the examples will most likely need to be adapted to fit your environment.
New features and updates are largely user-driven based on feedback and contributions.
The current project status is alpha meaning that it is neither feature complete nor has it been tested heavily. It will successfully build and launch a new GCS node, add it to an existing GCS endpoint and remove it from the endpoint when the container exits. It has several limitations:
- Must run in host network mode to support large inbound data port ranges.
- Must be bound to TCP port 443. This limits GCS containers to one per node.
- Each GCS container requires a unique public IPv4 address.
- Requires a secondary GCS installation for access to the GCS ClI. The secondary installation only requires package installation; a configured endpoint is not required.
- Custom domains are not supported.
- Custom TLS certificates are not supported.
- OIDC is not supported.
- The container runs multiple GCS processes in a single container.
- Messages to STDOUT within the container are not redirected in any way.
- Use of the POSIX connector will require additional effort to mount local volumes and add accounts.
Follow the Globus Connect Server v5.4 installation instructions, section 3.6 "Open TCP Ports" and verify that the docker node has the correct network connectivity.
Although the GCS container will supply a functional GCS node for the endpoint, you will still need access to the GCS CLI which you will use to define and configure the GCS endpoint. Follow the GCS installation instructions for your appropriate Linux distribution.
Follow section 4.2 of the GCS quickstart guide to create the GCS endpoint. Once that is complete, you will have these artifacts:
- the Globus client id and secret used in the
endpoint setupcommand - a deployment key (default
deployment-key.json) generated byendpoint setup
Do not lose the three items, they are required for launching GCS containers.
Make sure Docker is installed and usable by the current user. The exact details of the installation are specific to your distribution.
Clone this repository.
git clone https://github.com/globusonline/globus-connect-server-deploy.gitBuild a new image based on the latest stable version of Globus Connect Server:
$ ./docker-build-gcsAfter the image has been created, the previous command tag the image with the product name and the version used during the image creation. The following shows a GCS image based on Globus Connect Server version 5.4.16-1:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
globus-connect-server 5.4.16-1 ec6a4bb57b3d 2 hours ago 399MB
globus-connect-serverv54 latest ec6a4bb57b3d 2 hours ago 399MBNow launch the container which will effectively add an additional node to your GCS endpoint:
$ GLOBUS_CLIENT_SECRET=<client_secret> ./docker-run-gcs <client_id> <deployment_key>Use docker log to monitor the launch of the container, if desired.
$ docker logs --follow $(docker ps -lq)
IP address not specified, using 52.89.136.78
Configuring endpoint
Starting services
Enabling module headers.
To activate the new configuration, you need to run:
service apache2 restart
Enabling module proxy.
To activate the new configuration, you need to run:
service apache2 restart
Considering dependency proxy for proxy_http:
Module proxy already enabled
Enabling module proxy_http.
To activate the new configuration, you need to run:
service apache2 restart
Module rewrite already enabled
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
service apache2 restart
Launching Apache httpd
/usr/sbin/apachectl: 99: ulimit: error setting limit (Operation not permitted)
Setting ulimit failed. See README.Debian for more information.
Launching GCS Manager
Launching GridFTP Server
Launching GCS Assistant
GCS container successfully deployedThe administration of the endpoint is doing via the GCS CLI installed earlier. You can log in to the endpoint from the GCS CLI using the <client_id> used when the endpoint was setup.
$ globus-connect-server login <client_id>From that point on, configuration of the endpoint (except node setup/cleanup) is performed via the GCS CLI. See the Data Access Guide for details.
Use the docker stop command to terminate a running GCS container. This will send SIGTERM followed by SIGKILL after a brief interval which will forcibly terminate the container. The default interval between SIGTERM and SIGKILL is 10 seconds. This may not be long enough to allow GCS to exit cleanly. It is highly recommanded to increase the timeout to 30 seconds or more:
$ docker stop --time=30 <container_id>The container's exit procedures will remove this node from endpoint definition. It is not necessary to maintain any state from the container.
Some deployments will require local modifications to the GCS image in order to support additional features, for example, to modify the image to support POSIX account lookup in a manner that is compatible with your organization. This should be fairly trivial using a custom Dockerfile that builds upon the Dockerfile in this repository. The key is to specify FROM globus-connect-server:latest at the start of your Dockerfile.
Note that custom images that are derivatives of the image built by the tools in this repository will need to be rebuilt for each successive release of Globus Connect Server.
In order to have a functional POSIX collection, you'll need to modify the image to support POSIX account lookup (see 'Extending the Dockerfile') and you'll need to mount POSIX data volumes into the running container. Some important notes with respect to these modifications:
- Do not overwrite
/etc/passwdwithin the container, it is required for looking up GCS service accounts. - You can not mount at
/within the container. - The recommended way to serve data from the local host is to mount the volumes within a subdirectory of the container (ex.
/data) and set that subdirectory as theBASE_PATHduring collection creation. See the CLI Reference for details oncollection create.
The current GCS image design stores logging information to the container and does not persist the log entries after the container is terminated. In order to persist logging between invocations, it is necessary to specify docker volumes for each of the GCS service log files or directories. The log locations within the container are documented in section 6 of the GCS documentation.
In order to persist the log files, modify the example docker-run-gcs script to mount a volume at the log file location. For example, to capture all logs:
[ -d logs/globus-connect-server/gcs-manager ] || mkdir -p /var/log/globus-connect-server/gcs-manager
[ -f logs/globus-connect-server/gcs-manager/gcs.log ] || touch logs/globus-connect-server/gcs-manager/gcs.log
[ -f logs/gridftp.log ] || touch logs/gridftp.log
[ -f logs/gridftp-audit.log ] || touch logs/gridftp-audit.log
docker run \
--rm \
--detach \
--network host \
--env-file $tmpfile \
--mount type=bind,source="$(pwd)"/logs/gridftp.log,target=/var/log/gridftp.log \
--mount type=bind,source="$(pwd)"/logs/globus-connect-server,target=/var/log/globus-connect-server/gcs-manager/gcs.log \
--mount type=bind,source="$(pwd)"/logs/gridftp-audit.log,target=/var/log/gridftp-audit.log \
globus-connect-serverv54:latest
All work is copyright the University of Chicago. All rights reserved.
Please direct all support questions to support@globus.org. For technical discussions or contributions, feel free to contact jasonalt@globus.org.