PoC to deploy with quadlets #255
Conversation
ec8c8ec to
da3d557
Compare
|
@ekohl Have you seen examples of how we could test both deployment paths where a clean setup is needed for each? We would want to run through all acceptance tests, and then switch to container based and re-run all of them again. |
There was a problem hiding this comment.
AFAIK you still need to ensure service is running/stopped. Perhaps we need to go a similar route as with others where you explicitly ensure tomcat is running/stopped and the same for the container service. We probably don't need to go as far for the packages to be absent too just yet.
templates/candlepin.container
Outdated
| Volume=/etc/tomcat/logging.properties:/etc/tomcat/logging.properties | ||
| Volume=/etc/tomcat/server.xml:/etc/tomcat/server.xml | ||
| Volume=/etc/tomcat/login.config:/etc/tomcat/login.config | ||
| Volume=/etc/tomcat/cert-roles.properties:/etc/tomcat/cert-roles.properties | ||
| Volume=/etc/tomcat/cert-users.properties:/etc/tomcat/cert-users.properties | ||
| Volume=/etc/tomcat/conf.d/jaas.conf:/etc/tomcat/conf.d/jaas.conf | ||
| Volume=/etc/tomcat/tomcat.conf:/etc/tomcat/tomcat.conf |
There was a problem hiding this comment.
My reasoning behind using tomcat@ on Matrix was that we can use /etc/candlepin/tomcat or similar instead of /etc/tomcat. Then you can just mount that whole directory.
Perhaps we can start with using $tomcat_conf in here instead of hardcoding /etc/tomcat to make it portable.
There was a problem hiding this comment.
Perhaps we can start with using
$tomcat_confin here instead of hardcoding/etc/tomcatto make it portable
We can definitely move this to be a template using variables, that was a next step. First step was just getting it to pass tests (which it finally did).
My reasoning behind using
tomcat@on Matrix was that we can use/etc/candlepin/tomcator similar instead of/etc/tomcat. Then you can just mount that whole directory.
I don't think I understand what the config directly has to do with the service name, but, honestly I would rather just the service be called candlepin and abstract away the tomcat part.
There was a problem hiding this comment.
On EL 8+ you have tomcat.service which is a global since instance and tomcat@.service which uses /var/lib/tomcats/$NAME instead of /etc/tomcat. It's the multi-instance solution.
And I agree candlepin.service would be better. You can probably create a systemd drop in that adds the alias for you so you can use systemctl $action candlepin.
|
I think one area worth noting is in the space of configuration. podman's quadlets has the ability to re-use some Kubernetes resources in order to bring cohesion between the deployments. For configuration, that's embracing ConfigMaps and defining configuration through this method (e.g. https://github.com/ygalblum/quadlet-demo/blob/main/quadlet-files/envoy-proxy-configmap.yml which can be read about via https://www.redhat.com/sysadmin/multi-container-application-podman-quadlet). I think that more Kube-native method would shift how we think about configuration. |
|
I can imagine that we can still manage the config maps with Puppet. In theory the inputs that we want to tweak are the same, but the output format is different. That's what this module should provide: an abstraction where you can say "give me a candlepin that behaves in a certain way" and on a higher level (puppet-katello) we don't need to think about implementation details. Of course, that's theory. |
990e6ed to
4973d52
Compare
| 'image' => $candlepin::container_image, | ||
| } | ||
|
|
||
| file { '/etc/containers/systemd/tomcat.container': |
There was a problem hiding this comment.
I'd also be tempted to try southalc/podman#83. Comparing the two, your code doesn't take care of the daemon-reload that's needed when it changes. If we end up doing more with quadlets then it'll reduce the duplication.
97c62a6 to
adb63eb
Compare
| Volume=/etc/tomcat/server.xml:/etc/tomcat/server.xml:Z | ||
| Volume=/etc/tomcat/login.config:/etc/tomcat/login.config:Z | ||
| Volume=/etc/tomcat/cert-roles.properties:/etc/tomcat/cert-roles.properties:Z | ||
| Volume=/etc/tomcat/cert-users.properties:/etc/tomcat/cert-users.properties:Z | ||
| Volume=/etc/tomcat/conf.d/jaas.conf:/etc/tomcat/conf.d/jaas.conf:Z | ||
| Volume=/etc/tomcat/tomcat.conf:/etc/tomcat/tomcat.conf:Z | ||
| Volume=/etc/candlepin:/etc/candlepin:Z | ||
| Volume=/var/log/candlepin:/var/log/candlepin:Z | ||
| Volume=/var/log/tomcat:/var/log/tomcat:Z |
There was a problem hiding this comment.
In my testing of a completely unrelated application I didn't need :Z, but I was using plain volumes. Is this really needed?
There was a problem hiding this comment.
I think it depends on the application, the path, if it's read-only or read-write needed and SELinux policy as I understand it.
These two have some useful info:
| Volume=/var/log/candlepin:/var/log/candlepin:Z | ||
| Volume=/var/log/tomcat:/var/log/tomcat:Z |
There was a problem hiding this comment.
Can we configure candlepin (and Tomcat) to log everything to the journal and avoid these log directories?
There was a problem hiding this comment.
Fair question - generally I think yes. There are some things already logged to the journal but not everything.
| java_package => 'java-17-openjdk', | ||
| java_home => '/usr/lib/jvm/jre-17', | ||
| artemis_client_dn => Deferred('pick', ['', 'CN=ActiveMQ Artemis Deferred, OU=Artemis, O=ActiveMQ, L=AMQ, ST=AMQ, C=AMQ']), | ||
| use_container => #{container}, |
There was a problem hiding this comment.
I'm not that happy with the duplication and essentially templating. For the container use case I assume the java_* parameters aren't needed, so perhaps just duplicate the whole file into both container.pp and package.pp files?
No description provided.