...
Prepare for building
...
an image
...
- The needed files can be obtained from the
...
- TIER github repository
- It's best to be in a new empty directory. You can create a new one with a name you like and/or the command below will create a new child directory in your current directory named shib-idp_noVM
- git clone https://github.internet2.edu/docker/shib-idp_noVM
Decide on a config type
Burned
All configuration is supplied when the image is built and is “burned” into the resulting image. The image stands alone and has no external dependencies, but contains sensitive information in the images (like passwords, private keys, etc.). To update the configuration, new images are built and rotated into production. This image cannot take advantage of the IdP’s automatic configuration reloading features.
Mounted
All configuration is dynamically mounted at run-time. The resulting image will
...
be dependent upon the presence of local configuration files on all docker nodes that run the container (so, as a result, the image does not stand alone).
...
These types of images do not contain sensitive information.
...
Further, these images are able to take advantage of the IdP’s automatic configuration reloading features. To update the configuration, it is necessary to sync the updated file(s) to each docker node running the container (a script is provided for this).
...
The script's synchronization process
...
requires a regular user account on all swarm nodes to
...
be used for syncing files. The critical part of this is that a single public/private keypair will need to be used for this user on all nodes and the syncFilesToAllNodes.sh script will need access to the private key from this keypair (the script will only run on the manager node).
...
Steps to create this user account are:
On Manager node(s):
useradd -m -d /home/swarmuser -s /bin/bash swarmuser
sudo -u swarmuser ssh-keygen
...
(leave password blank)
sudo -u swarmuser cp ~swarmuser/.ssh/id_rsa.pub ~swarmuser/.ssh/authorized_keys
cat ~swarmuser/.ssh/authorized_keys (then copy/paste to worker nodes)
On Worker node(s):
useradd -m -d /home/swarmuser -s /bin/bash swarmuser
sudo -u swarmuser mkdir -p ~swarmuser/.ssh
sudo -u swarmuser chmod 700 ~swarmuser/.ssh
sudo -u swarmuser vi ~swarmuser/.ssh/authorized_keys (then paste the key from above)
- Hybrid
...
- This type of configuration looks mostly like the ‘burned’ type detailed above, with the exception that all sensitive information, along with the most dynamic config files for the IdP, has been
...
- removed from the built image and will instead be supplied at run-time
...
- using docker secrets. Therefore, these images do not contain sensitive information.
...
- They can use the IdP’s automatic configuration reloading
...
- , but only if the changed configuration file was previously defined as a docket secret (and the secret had been updated in the docker swarm). Unlike the mounted type of configuration, this config type does not require manually syncing config files to all docker nodes (or the creation of user accounts to enable
...
- such syncing).
...
- For the default hybrid configuration, the following IdP files are defined as secrets:
- idp-signing.key
- idp-signing.crt
- idp-encryption.key
- idp-encryption.crt
- keystore.jks (tomcat/SSL)
- sealer.jks
- sealer.kver
- idp.properties
- ldap.properties
- relying-party.xml
- attribute-filter.xml
- attribute-resolver.xml
- metadata-providers.xml
- For the default hybrid configuration, the following IdP files are defined as secrets:
Build your config
Use the configBuilder.sh script (in the files from github)
After building your IdP config, this script will create a timestamped archive/zipfile with all of your config bits (including sensitive information).
If you choose a ‘hybrid’ build type, then this script also creates a new child directory named ‘ConfigNoSecrets’ which contains your configuration, but with all secrets moved to a separate directory (including some of the more dynamic config files).
Info you’ll need for this script:
FQDN of your IdP
Attribute scope value for your IdP (typically your main domain name)
LDAP info
LDAP URL
LDAP Base DN
LDAP service account DN for the IdP
Password on the above account
Config type (see above)
BUILD your image
(runDo this work from the same directory
where
your Dockerfile is located
Mounted (you’ll need to transfer your built config to your manager VM if you built it elsewhere)
docker build --rm -t my/shibb-idp-tier .
Burned (assuming default directories generated by the configBuilder.sh script)
docker build --rm -t my/shibb-idp-tier .
Hybrid (you’ll need to transfer your secrets to your manager VM)
The first command below establishes an alternate location for the config bits (which then gets used in the subsequent ‘docker build’ command). The default directory referenced is produced by the configBuilder.sh script and has the secrets extracted from the main config. This means that the resulting image will be burned with an incomplete config (some files will be missing). That config will be completed at run-time when the predefined secrets are added by docker.
export ALTCFG=ConfigNoSecrets
docker build --rm -t my/shibb-idp-tier --build-arg TOMCFG=${ALTCFG}/config/tomcat \
--build-arg TOMLOG=${ALTCFG}/logs/tomcat \
--build-arg TOMCERT=${ALTCFG}/credentials/tomcat \
--build-arg TOMWWWROOT=${ALTCFG}/wwwroot \
--build-arg SHBCFG=${ALTCFG}/config/shib-idp/conf \
--build-arg SHBCREDS=${ALTCFG}/credentials/shib-idp \
--build-arg SHBVIEWS=${ALTCFG}/config/shib-idp/views \
--build-arg SHBEDWAPP=${ALTCFG}/config/shib-idp/edit-webapp \
--build-arg SHBMSGS=${ALTCFG}/config/shib-idp/messages \
--build-arg SHBMD=${ALTCFG}/config/shib-idp/metadata \
--build-arg SHBLOG=${ALTCFG}/logs/shib-idp .Tag your new image for shipping to the private repository
docker tag my/shibb-idp-tier repo.training.incommon.org:5000/shib-idp-tier:<your userID>
SHIP your image to the private repo for this training class (an instance of the Docker Private Repo)
First, add an entry to your /etc/hosts file (on both manager and worker nodes)
172.31.10.102 repo.training.incommon.org
docker login repo.training.incommon.org:5000
Username: incommontrain
Password: CheckWithMe
docker push repo.training.incommon.org:5000/shib-idp-tier:<your userID>
Start a new docker swarm with your 2 VMs
If needed, set rules in firewalld on all swarm nodes (and disable selinux, if applicable)
...
*For a “mounted” config type
First sync config content to all swarm nodes (from Dockerfile dir)
./syncFilesToAllNodes.sh build swarm-idp-config swarmuser swarmuser
RUN a new service on your swarm
Burned
docker login idp.training.incommon.org:5000
...
Check your new service
docker service ls
docker service inspect shib-idp
docker service ps shib-idp
docker ps (on a node running the new service)
To get a shell in one of your containers:
docker exec -it <containerID> bash
Changing the configuration of an existing service
Burned
Update the appropriate config file in the directories setup by the configBuilder.sh script (child directories from the Dockerfile directory). Most Shib-IdP config is in ‘config/shib-idp/conf’.
Re-run the same build command from step 2.b above, with the change below, to build and push a new image.
Modify the build command slightly (apply a tag as in ‘newBuild’ below) to ensure your new build has a unique name
docker build --rm -t my/shibb-idp-tier:newbuild .
docker tag my/shibb-idp-tier:newbuild repo.training.incommon.org:5000/shib-idp-tier-newbuild:<your userID>
docker login repo.training.incommon.org:5000
docker push repo.training.incommon.org:5000/shib-idp-tier-newbuild:<your userID>
Apply a service update to your swarm to roll in the new image
docker service update --update-parallelism 1 --update-delay 60s --image repo.training.incommon.org:5000/shib-idp-tier-newbuild:<your userID> shib-idp
...