Alpine / unified

[hexylena]

• switches to alpine build based off quay.io/gmod/docker-apollo:unified (i.e. the unified branch here)
  • the unified branch is based off of the bare (aka apollo-only) branch, i.e. what admins should deploy.
• Persistence is removed, i.e. cannot -v pgdata:/var/lib/postgres/data
  • This allows chado to come pre-installed, which saves ~1min off of startup.
  • I think this is an acceptable tradeoff. We do not want to encourage people to deploy the non-bare images, those should be for playing around and deciding if you want to use apollo. If you actually want to deploy, it should definitely be done via apollo-only/bare images.
• https://quay.io/repository/gmod/docker-apollo?tab=tags yay decreased vulnerabilities!
• fixes #17
• supersedes #18
• environment variables are currently not a solved problem, but, again, this isn't for production purposes so this is probably fine. I have some solutions in mind, just need to implement.

If you're fine with this, I'll start work on tagged releases. This way people can pull things like :apollo2.0.6-unified and :apollo2.0.6-bare (though I strongly, strongly suspect that only people running on the bare branch actually care about tagged releases like this) and will add the commits for the 2.X series of releases so far.

[nathandunn]

Thanks I'll take a look next week.

[nathandunn]

@erasche Finally had a chance to look at this.

I'm confused. Is the implication that I'm to bring in #18 (which is fine). I want to provide something where a user (any user) can continue to go in and mess with the docker file if need be.

I like the idea of users connecting with a mounted volume. While we have users providing solutions to a larger user-base (like yourself), which are better than what I am providing, we also have users providing a server for a lab for a month and want something that can load up quickly and be used for a month and then tossed. I think I have in #18 works really well for that.

I think we just need to sync up. My guess is what you have for the minimal case is what we want moving forward (for the minimal case), but we're going to want a few more versions for some of our other users.

We might just need to touch bases on gitter when you have a moment.

[hexylena]

I'm confused. Is the implication that I'm to bring in #18 (which is fine).

This should address everything in 17/18, those should be closed/not merged with this PR.

I want to provide something where a user (any user) can continue to go in and mess with the docker file if need be.

Is that what your end users are asking for? What sort of modifications are they asking to make?

• Apollo core code changes: should not be done in the container, they will lose their work, they will be unhappy. This is not the place to develop apollo. Most users making code changes want to use their IDE, it is simple enough to say "fork on github, make change, point this dockerfile at your own git repo". Very few projects do this in my experience, none of the big ones.
• Plugin changes: very few people run as many organisms as we do (and if they do, they're big time admins), so it's easier for them to continue to add them to their existing JBrowse confs.
• What docker changes are you imagining? I'm probably not aware of use cases outside what we worked on.

Here are the target users that I can imagine, but my imagination may be limited. Personally, I think there is little intersection between the following user groups:

Hypothetical User	Stack they should use	Modifications?
Kitematic user testing out Apollo	unified	probably isn't going to make modifications
Beginner bioinformatician setting up stuff for their lab who is semi-comfortable with linux CLI	happy to use docker-compose when we say "if you want to persist data, use this"	probably isn't going to make modifications because they're busy annotating
Linux admin	will prefer docker-compose, since that will work with their existing cloud infra	also isn't going to modify, and if they do they would want to modify the base image.
Advanced bioinformatician who wants to make modifications	Directed to docker-compose	All the modifications I can think of (java/js changes) require re-building, and they should not rebuild apollo within the container, they will lose their work and be unhappy. They should modify the dockerfile and rebuild that.

I like the idea of users connecting with a mounted volume.

This is possible here.

While we have users providing solutions to a larger user-base (like yourself), which are better than what I am providing, we also have users providing a server for a lab for a month and want something that can load up quickly and be used for a month and then tossed. I think I have in #18 works really well for that.

This is a huge part of my argument for the base image without code in it, rather than a unified image.

If you're targeting labs who want to set it up for a month, they should be using the docker-compose version which is way easier to set up than knowing how to invoke the unified image with the directories in the right place. Using the unified you have to copy an ugly command line and it's hard to see what's going on since you get the logs from one service (apollo) and none of the others.

If they had started out with docker-compose, they would be able to separately see and run commands within each container. Here's an example of how their life is qualitatively better:

Task	Unified	docker-compose	notes
Tail postgres logs	docker exec -it $apollo_id tail -f /var/log/postgres.log	docker-compose logs postgres
Running	docker run -it -p 8080:8080 -e {env vars} -v /home/user/apollo/testing/db:/var/lib/pg_data -v ... quay.io/gmod/docker-apollo:latest	docker-compose up
running a one-off postgres query	docker exec -it $apollo_id psql -h localhost -U apollo -W apollo ...	docker-compose exec postgres psql
Mounting a DB Volume	docker ... -v /full/path/to/directory:/var/lib/pg_data/I/have/to/look/this/up/every/time	docker-compose up (already done)	And we have to re-implement the postgres init to be similar to how official postgres conatiners do it, duplicating code / effort.

I think we just need to sync up. My guess is what you have for the minimal case is what we want moving forward (for the minimal case), but we're going to want a few more versions for some of our other users.

This is the non-minimal case in this branch, hence my surprise at these comments.

We might just need to touch bases on gitter when you have a moment.

If it's ok with you, I'd prefer to have the discussion here as long term documentation for rationale behind decision making.

[nathandunn]

Thanks @erasche very thorough. This is looking awesome (now that I understand it). To summarize what I wrote below.

• add a link in the docker file to the root source (even if its in a branch)
• add awesome table with commands and use-cases (esp. as it includes mounting the database)
• add missing docker-compose file?

=== Details below ===

I'm just going to comment on places where I have questions / comments. Otherwise assume that I agree:

What docker changes are you imagining? I'm probably not aware of use cases outside what we worked on.

I want something where they can look at how the image is generated so that they can make their own modifications or at least understand what is going on. Was hoping that could be here for each branch.

Of course, if its just this: https://github.com/GMOD/docker-apollo/tree/unified that is fine. Just link to the source somewhere (maybe above the "from" in the Dockerfile, even if its obvious now. Can be https://). Wasn't sure if that was done yet or not.

# https://github.com/gmod/docker-apollo/tree/<branch>
# quay.io/gmod/docker-apollo:<branch> 

If you have a better idea that's fine.

I like your user run-down and I think I understand the PR better now and it all makes sense.

If they had started out with docker-compose, they would be able to separately see and run commands within each container. Here's an example of how their life is qualitatively better:

You should put this awesome table in the doc if possible. Even the other one wouldn't hurt.

My only caveat is that I don't see a docker compose file. Was there supposed to be one for docker-apollo, or were they supposed to create their own file or use another repo?

If it's ok with you, I'd prefer to have the discussion here as long term documentation for rationale behind decision making.

That's fine.

[nathandunn]

There are a ton of advantages of this PR over what is there. I kind of want to move it into its own repo, though.