Hello Alex;
The 'attached storage' approach to the secrets described below seems like it
would work well; I should be able to change the launch system to pickup those
settings in that way.
I can rework the HDS release process so that it moves a build product [1] to
remote storage and then the Docker build can be run such that it will download
that "war" file again as part of assembling the Docker image -- essentially as
you suggest below. The HDS release process is driven by a python file so is
flexible enough to accommodate this change. Releases are currently being
undertaken on my development system so it would be most convenient if the
release script could drop the HDS build product into a Haiku-infrastructure
storage point using the "scp" tool or similar. Is that possible? If somebody
can set that up for me, I can take it from there.
Regards;
[1] https://en.wikipedia.org/wiki/WAR_(file_format)
--
Andrew Lindesay
www.lindesay.co.nz
On Tue, 31 Jul 2018, at 16:51, Alexander von Gluck IV wrote:
Good morning!
Sorry, I wasn't on haiku-depot-web so never saw this. Lets try to dig in:
Andrew Lindesay wrote:
To help with the current "dockerization" project, I have been working to
get
the HDS build process to generate a Docker image. You can find this in the
"138-docker-image-build-product" branch. To try this out, install;
* Maven >= 3.x
* Java 8
* Docker
Then issue this command from the top level of the project;
mvn -Pdocker-capable-build package
In the console you will see the image ID at the end;
...
[INFO] Step 34/34 : EXPOSE ${HDS_PORT}
[INFO]
[INFO] ---> Running in 4f24d0a32248
[INFO] Removing intermediate container 4f24d0a32248
[INFO] ---> 68e06c4bed68
[INFO] Successfully built 68e06c4bed68
This doesn't fit 100% into the "standard docker workflow"
Most automation is based around docker consuming a Dockerfile
and building a container around "versioned/released" binary
artifacts from a remote location.
("wget http://app.com/version/v1.0.0.tar.gz", etc)
If this *is* the route you want to go, the haikudepotserver
project will need to manage building and pushing its versioned
container to a public repository.
(hub.docker.com, registry.fedoraproject.org, quay.io, docker.io, etc)
To launch an HDS container....
docker run \
-e "HDS_JDBC_URL=jdbc:postgresql://somepghost:5432/haikudepotserver" \
-e "HDS_JDBC_USERNAME=somepguser" \
-e "HDS_JDBC_PASSWORD=somepgpassword" \
-e "HDS_SMTP_HOST=somesmtpserver" \
-e "HDS_AUTHENTICATION_JWS_ISSUER=justtesting.hds" \
-p 8080:8080 \
"4b107e2ac128"
We need to find a better way of storing passwords.
One common method we have utilized is having the environment
variables in a file on a persistent storage device and sourcing it:
Example:
Docker volume "hds_secrets" /hds_jdbc:
HDS_JDBC_URL=jdbc:postgresql://somepghost:5432/haikudepotserver
HDS_JDBC_USERNAME=somepguser
HDS_JDBC_PASSWORD=somepgpassword
HDS_SMTP_HOST=somesmtpserver
docker run \
-e "HDS_AUTHENTICATION_JWS_ISSUER=justtesting.hds"
-e "HDS_SMTP_HOST=somesmtpserver"
-p 8080:8080 \
-v hds_secrets:/secrets
Then, the startup script can source /secrets/hds_secrets
That isn't a great option, but it means we can open up more
of our configuration without exposing credentials.
Haikudepot also doesn't need to worry about SSL certificates,
they are handled at our frontend reverse proxy.
Thoughts?
-- Alex
