harding-university / hubado Goto Github PK

We should have a way to collect and analyze the logs from the containers, particularly as they get increase in number.

I'm beginning to wonder if we're drifting too far from the intent of make, and we'd be better off with a Python script.

We likely don't need to chown all of the tomcat directory to the tomcat user.

Oracle publishes the .jar files we need in /vendor; maybe we can pull them automatically

eeamc needs to be set up as described in the install guide; right now it's not fully implemented.

Perhaps by only allowing a specific IP range or HAProxy ACL configuration.

The Makefile is getting a little chaotic. It could use a once-over and some more comments explaining things.

It would be useful for setting up new instances to include some system recommendations for the host server, even if they're just ballpark guesses.

Current docs say ESM building is deprecated and instruct in Hubado building. This should be updated to reflect the current situation.

For example, even just checking if:

• Each application is up (e.g. not 404ing)
• Certain URLs are redirecting properly to SSO

would be plenty useful. I'm sure we could come up with other tests if we thought about it.

Upsteam fix for CVE-2022-35912 doesn't create a new artifact (at least for appnav), so the patch won't get applied with the current build-from-artifact setup. Investing why. In the meantime, reapplying manual Grails patch.

The metrics volumes, at least, shouldn't be pruned without an explicit command.

A few minor things have changed and new features have been added.

Right now the Jenkins service is needed to supply WARs to most of the Tomcat images. The appnav service instead builds the WAR from *.trz upgrade artifact, and that seems like the preferable way to do things. It removes the dependency on the Jenkins service and the accompanying Jenkins node and ESM wget config. It also makes Hubado the authority on what version of the WAR is built, vs. whatever happened to be last deployed in ESM.

And perhaps a container to run it in.

The Dockerfiles need a pass to both 1) group sequential RUNs into a single command and 2) ensure the commands are ordered in an efficient way.

Right now, the RabbitMQ creds are part of the standard environment given to all Tomcat servers, but most of servers don't need them.

There's a lot of repetition in the Tomcat Dockerfiles. Perhaps we can create a template or otherwise set them up to share a lot of the common code.

SSB9 apps need session timeouts implemented.

Right now, Tomcat runs as uid 1000. It should use the hubado user.

If it's easily available somewhere in the WAR, it would be useful to be able to quickly check what versions are deployed, particularly if we stick with the Jenkins container (which is becoming more likely).

Right now, a .war for every application in Hubado must be present to build using normal commands. We should handle that better (e.g. just don't stand up services with missing WAR files).

If a Makefile-specified artifacte (e.g. APPNAV_ARTIFACT) is changed and make contexts is run, the old .trz will remain in the build context. This breaks the docker compose build process, because it can't copy both artifacts to a single filename.

The workaround is to run make clean and make contexts again, but ideally the Makefile should account for this. We can probably do so by clearing out any existing .trzs when coping a new one.

Rabbitmq message queue may need a persistent volume in case Docker restarts while data is being pulled.

Most of the haproxy configuration could be generated instead of being manually maintained.