Skip to content
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

Refactor startup scripts, envvars for all omero parameter #1

Merged
merged 17 commits into from
Jul 13, 2017

Conversation

manics
Copy link
Member

@manics manics commented Jun 5, 2017

Refactor the startup-scripts for OMERO.server:

  • All omero config properties can be set with environment variables
  • Database setup is separate from starting OMERO.server
  • Removed OMERO.grid support- this will be added back in a separate dependent repo
  • Use dumb-init
    • @dpwrussell In theory this means you could start a backgrounded script which polls localhost to check whether the server is ready before creating a public user, before the final 99-run.sh script is run, avoiding the requirement to restart the server.

Copy link
Member

@dpwrussell dpwrussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the rationale for not just calling the run-exec.sh file run.sh? That seems to be the norm.

50-config.py Outdated


for (k, v) in os.environ.iteritems():
omero = '/opt/omero/server/OMERO.server/bin/omero'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need not be in loop

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and probably should be caps

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@manics
Copy link
Member Author

manics commented Jun 6, 2017

I've renamed run-exec.sh to entrypoint.sh

@dpwrussell
Copy link
Member

Works as expected.

README.md Outdated
-e CONFIG_omero_db_name=postgres \
-e ROOTPASS=omero-root-password \
-p 4063:4063 -p 4064:4064 \
-e ROOTPASS=omero openmicroscopy/omero-server
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ROOTPASS twice?

@@ -12,13 +12,15 @@ RUN yum -y install epel-release \
ARG OMERO_VERSION=latest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're using the main release version (i.e. 5.3.2) for tags of this repo, then I'm assuming:

  • latest images are considered worst-practice
  • on each OMERO release, we'll branch from master and bump this string to include the version (5.3.3)
  • for bug fixes before an OMERO release, we'll suffix 5.3.3-1

Note: this doesn't yet give us a strategy for breaking changes in the image itself

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming this has everyone's implicit 👍 but now with 5.4 replacing 5.3

DBHOST="$CONFIG_omero_db_host"
else
DBHOST=db
$omero config set omero.db.host "$DBHOST"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be outside the if block?

Copy link
Member Author

@manics manics Jun 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, CONFIG_omero_db_host will already be converted into omero.db.host by 50-config.py- I'll update the comment at the top of the file. The only reason for special handling here is that the default of omero.db.host=localhost will never work, instead it defaults to db which should be set by docker run --link ....

50-config.py Outdated
@@ -0,0 +1,20 @@
#!/usr/bin/env python
# Set omero config properties from CONFIG_ envvars
# Variable names should replace "." with "_" and "_" with "__"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not particularly worried but there's obviously some danger of a __ conflict here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know. Do you have another suggestion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how evil this is but:

$ env "a.b=1" python -c "import os; print os.environ['a.b']"
1
$ docker run -ti --rm -e a.b=1 centos python -c "import os; print os.environ['a.b']"
1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortuntately it's also used in the bash script60-database.sh

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Continuing discussion under #3

README.md Outdated
docker run -d --name postgres -e POSTGRES_PASSWORD=postgres \
-v omero-db:/var/lib/postgresql/data postgres
docker run -d --name omero-server --link postgres:db
-e CONFIG_omero_db_pass=dbpassword -v omero-data:/OMERO \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example isn't working for me:

FATAL:  password authentication failed for user "omero"
DETAIL:  Connection matched pg_hba.conf line 95: "host all all 0.0.0.0/0 md5"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to repeat all the -e CONFIG_omero_db_* params from the previous example, I'll try and make that clearer

@manics
Copy link
Member Author

manics commented Jun 7, 2017

BTW, I've just realised https://github.com/openmicroscopy/omero-server-docker/blob/master/requirements.yml#L21 means this can't be tagged as production until ome/ansible-role-omero-server#12 is tagged

@manics manics closed this Jun 8, 2017
@manics manics deleted the devel branch June 8, 2017 10:31
@manics
Copy link
Member Author

manics commented Jun 8, 2017

oops...not sure what happened...

@manics
Copy link
Member Author

manics commented Jun 8, 2017

I had a typo, accidently did git push ... -d.

@manics manics reopened this Jun 8, 2017
@joshmoore
Copy link
Member

I had a typo, accidently did git push ... -d.

That's kinda scary. Good to know.

@manics
Copy link
Member Author

manics commented Jun 8, 2017

Updated in response to @joshmoore's comments.

In addition I've switched from loading .omero files from /config/ to /opt/omero/server/config/ as used in https://github.com/openmicroscopy/ansible-role-omero-server/tree/2.0.0-m1

One issue you may want to consider before ansible-role-omero-server is officially tagged 2.0.0: the configuration script /opt/omero/server/config/omero-server-config-update.sh is in the same directory that's used for .omero files /opt/omero/server/config so you can mount .omero files but not the entire directory.

@joshmoore
Copy link
Member

joshmoore commented Jun 13, 2017

Discussion now points to:

@manics
Copy link
Member Author

manics commented Jul 3, 2017

--depends on ome/omego#108

  • This needed to allow installations without a DB to proceed
  • You can temporarily test this using manics@34b1b07

Copy link
Member

@dpwrussell dpwrussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there could potentially be mounted filesystems that might want to be mounted as the same UID as the omero server, should this be made configurable? The host os is likely to have more restrictions on what uids they can use than the container one.

@joshmoore
Copy link
Member

No objections from my side to having uid and gid be ARGs, but in general, then, you could also subclass the image and usermod. More critical from my POV is: what's the expectation when pulling the image from hub?

To your question in particular: I haven't run into a situation where I can't chown the directory with a particular UID before mounting but I could imagine not wanting to if that were to put something in particular at risk. (i.e. I don't trust the 1000 user on the host system in question)

@manics
Copy link
Member Author

manics commented Jul 7, 2017

@dpwrussell I agree with you. The correct way to solve this is to treat the omero-server Docker filesystem as readonly with the exception of defined directories for logs and temp-files (which is our long-term goal) which will need to be mounted as volumes. Then you can simply use docker run --user UID ... to set the user OMERO runs as.

The purpose of the last commit is to make the default omero-server UID well-known as opposed to using whatever useradd picks as the UID.

@manics
Copy link
Member Author

manics commented Jul 7, 2017

Though what would be even better is if all OMERO logs went to stdout/stderr, so just /tmp would need to be writeable (which it generally is by any user).

@joshmoore
Copy link
Member

latest is now 5.4. Shall we go with the flow and this repo matches the milestones of the 5.4 series with the intent of releasing this as production with 5.4.0?

cc: @dpwrussell @manics @sbesson @jburel

README.md Outdated
/config/extra.omero:/opt/omero/server/config/extra.omero:ro
openmicroscopy/omero-server

Parameters required for initialising the server such as database configuration *must* be set using environment variables.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

initializing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed

@joshmoore
Copy link
Member

Re-ran travis to get this green. Merging, untagged. I'd suggest when 5.4.0-m1 is tagged, that someone create a commit changing latest to v5.4.0-m1 and tag that commit which should then be built on hub.

cc: @mtbc

@joshmoore joshmoore merged commit 45635db into ome:master Jul 13, 2017
@ghost ghost mentioned this pull request Apr 8, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants