Generic containers and container dependency

[lfvJonas]

We are currently using test containers for testing, but we are thinking about moving to use Spring boot test container to make it possible to use the containers for both testing and dev environments.

We have had an eye for Arconia, but we are unsure about some stuff:

• Generic container support for our own created containers or non predefined
• Container dependency support some of our container depend on another container (ex. containerized spring boot application that depends on a containerized Artemis broker)

Can't seem to find anything in that matches these use cases in the documentation.

Is this something Arconia is meant to solve?

[lfvjimisola]

@ThomasVitale FYI, @lfvJonas and I work together.

[ThomasVitale]

@lfvjimisola Thanks for the questions and the interest in Arconia. I recently published a blog post that I hope helps describe a bit more the Arconia Dev Services.

• The Arconia Dev Services are built on top of Spring Boot's support for development-time Testcontainers, so you can use it next to the lower-level feature supported in Spring Boot. For example, you can add your own custom containers. I will soon extend the documentation to include more information about this case, and perhaps add an example in https://github.com/arconia-io/arconia-examples. I'll share an update here when that is done.
• Currently, Arconia supports only direct dependencies out-of-the-box. If you need to include a container for an application, which itself depends on an Artemis broker, then you can add your custom configuration using the Testcontainers APIs or use Spring Boot's support for Docker Compose and define those two containers in a compose.yml file.

[jimisola]

I'm not familiar with the Customizer pattern used Spring Boot. Will look it up but if you know of useful docs or examples please share links.

Do you have an idea on whether a configuration shall use the Customizer Pattern or not?

And with the Customizer pattern the idea is also then to circumvent the issue with ConfigurationProperties and complex typses

[ellakk]

Regarding OpenShift, OCP is very restricive with persmissions due to OpenShift’s Security Context Constraints (SCC) .

Hopefully, another former colleague @ellakk can ship in so that I'm not mistaking:

* OpenShift does not run containers as a fixed UID - it assigns a random high UID at runtime.

With the PostgreSQL image I seem to recall that it tried to change file permissions during startup fixing permissions on existing directory /var/lib/postgresql/data ... ok which caused an error such as changing permissions of '/var/[...]': Operation not permitted

Yes, this is correct, the UIDs are semi-random and are allocated per namespace, they start at 1000000000. The default SCC (restricted) is described as follows:
restricted denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive SCC and it is used by default for authenticated users

[ThomasVitale]

Thanks for the additional info! In the upcoming release 0.22.0, it will be possible to configure fixed exposed ports (thanks so much for contributing the functionality, @jimisola!) and also network aliases. For the next release, I hope to tackle configuring shared networks (#146).

[jimisola]

What is the plan for (should issues be created?):

• configuration of file system bindings?
• using a generic container (with waitStrategy etc)?

[ThomasVitale]

It would be great if you could create two GH issues for those two aspects, thank you!

[jimisola]

I seem to recall now that we handled observability a bit different as we wanted to use the Java Agent for wider instrumentation support .

That of course meant that we had to fix the ingestion port so that it was known during build time as there (to be knowledge) is no-way for the Java Agent to auto-detect the ingestion port during execution.

We disabled tracing by default and allowed user to enable it via system property or environment variable.

We handled all our dependencies using Maven Tiles (composition). Maven 4.1 will provide similar (better) functionality with the long outstanding support for mixins.

So, the tile/mixin, e.g. observability, will have these dependencies:

• dev-services
• all dependencies needed in test and compile scope (Maven)

This so that any Spring Boot project could just have a dependency on a tile (Redis, PostgreSQL etc) and that would pull in the necessary dependencies for that service as well as including the dev-service.

[jimisola]

Read the CONTRIBUTING.md. Does the project do "Squash and Merge" or just merge?

[ThomasVitale]

We try to squash the commits before merging the PR, so to have a linear history with a single commit per PR.