-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Add support for Bitnami container images with Docker Compose #35759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Results of using the changes in this branch to try the Bitnami container images:
This testing is fairly superficial. A second pass to look at the environment variables that each container supports and whether they work as expected is the next step. |
I'm likely stating the obvious here but the following changes services:
elasticsearch:
image: 'elasticsearch:8.6.1'
environment:
- 'ELASTIC_PASSWORD=secret'
- 'ES_JAVA_OPTS=-Xmx1024m'
- 'xpack.security.enabled=false'
- 'discovery.type=single-node'
ports:
- '9200'
- '9300' and services:
redis:
image: 'bitnami/redis:7.0'
environment:
- 'ALLOW_EMPTY_PASSWORD=yes'
ports:
- '6379:6379'
labels:
org.springframework.boot.service-connection: redis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We want to investigate how compatible our Docker Compose support is with Bitnami container images. The first part of this is the names of the images as we use the name to determine the type of the service in the container. If these don't match up, the
org.springframework.boot.service-connection
label can be used to as something of a workaround but it would be nice if it wasn't necessary. The second part of this is the environment variables in the started container that we look for to learn how to connect to the service. If the Binami images use different environment variables, we won't be able to figure out how to connect. I'm not sure that this can be worked around – perhaps by a user configuring custom environment variables that alias one variable to another – but this would be even clunkier than the image name workaround.The text was updated successfully, but these errors were encountered: