Revisit CLAW-Docker

[whikloj]

So now that we seem to have a semi-stable stack, perhaps learning how to create containers for the individual parts and building them would be the next step?

Especially as this could make development rebuilds much faster.

So I think we need containers for:

• MySQL/Mariadb
• Apache -> Drupal
• Apache -> Crayfish microservices
• Tomcat -> Fedora 4
• Tomcat -> Cantaloupe
• Karaf -> Alpaca
• Karaf -> API-X
• Blazegraph
• Solr
• JMS Message Broker

Some of these can be combined, not sure if we want to do that or not.

Thoughts?

[whikloj]

I do want to learn this, so I'm going to start learning some of this docker stuff in general and see what head-way I can make so once this ticket is fleshed out I might have a clue where to start. 😉

[ajs6f]

At least in theory, there is no reason that I can see not to put Alpaca and API-X in the same Karaf, and Fedora and Canteloupe in the same web container.

[ajs6f]

And after some IRC conv, I now understand that the reason to separate those things is because you might want to scale them separately.

[jonathangreen]

For what its worth, I believe the "docker way" to do things is to have one thing in each container, to make it easier to split up etc.

[ruebot]

All the existing Docker work lives here. That can be moved back over to the CLAW GitHub organization once we have a plan.

For posterity from irc, as parting director, I just don't want to see a free for all on stuff. I'd like to see some concentration on concrete work, and we go from there. It sounds like there is some coalescing around working on install after MVP. We should make that formal, and begin having conversations about how to implement that work. Identify stakeholders, identify functional requirements, and plan a sprints.

[ajs6f]

@ruebot Are there enough install-related tickets that we could make a Github project to begin to coalesce the conversation?

[whikloj]

I have no functional requirements, just interested in speeding up development machine rebuilds. But that being said, I think we should consider dumping some of the old docker builds. Not sure we need 2 JAVAs nor Solr on Tomcat anymore.

[ajs6f]

For SI, our functional requirements would include (I kind of hate to say it) a straightforward non-Docker install technique. We do not have dockerized production infrastructure and it is going to take a good while to get that going (could be several years).

[ruebot]

@ajs6f maybe we should start with a CLAW Call agenda item, and go from there?

[DiegoPino]

@ajs6f i agree on having a non-docker install technique, kinda feel current vagrant way of doing (and if not using directly vagrant just following the .sh files) things will be kept also right?

[ajs6f]

I do not pretend to any deep understand of this tech, but I think we can keep vagrant gear and use it to create docker images to some extent, right? I guess the degree to which we can do that depends on how many docker images we reuse and how many we create ourselves. I put an item on the next CLAW meeting agenda to talk about this.

[whikloj]

I'll probably want to keep vagrant now that I figured out how to use Xdebug inside... regardless we will need install documentation separate from Docker containers.

[ajs6f]

Vagrant provides a nice place to do certain kinds of documentation as inline comments. We'd need more, of course, but that's a pretty helpful form, because it is constantly checked and verified by execution.

[jonathangreen]

I would love to see the vagrant scripts replaced with an idempotent ansible config. That will speed up vagrant rebuilds, as we can just rerun the ansible configuration and get the changes, instead of having to totally rebuild. This could also be used as the basis for production deployments as well.

[dannylamb]

@jonathangreen apt packages could do the same for us. Avoiding total rebuild would be great for developers. Right now I manually comment out the scripts I know have already been run and re-execute vagrant provision, which is less than ideal in many many ways.

[jonathangreen]

@dannylamb I'm all for apt-packages. I think ansible could work nicely with apt packages to do the configuration and glue bits, but we could use shell scripts as well.

[ajs6f]

There is definitely an audience for RPMs, as well. We use RHEL in production, and that is basically not a choice we can change. (At least not on any interesting timescale.)

[DiegoPino]

@ajs6f i feel apt is closer to yum. Not sure if RPM is an equivalent, looks like to be lower level in the way it handles dependencies. Do you have a use for YUM? I heard of some people on islandoraCon that run Redhat, a certain 👀 @whikloj and a certain 👀 @edf 😀 . Seems to be enough quorum to make that deployment method a community contributed alternative which I for sure would like to support.

[ajs6f]

@DiegoPino Sorry, that's not what I mean-- I mean that whatever tool you use to manage packages, there are apt packages and RPM packages. You can use RPMs with yum or rpm or whatever, but you cannot use apt packages in an RPM system. Do you see what I mean? I'm not suggesting that CLAW needs to support any given tool as much as that it could release more than one style of artifact.

[dannylamb]

This is ISLE

• https://github.com/Islandora-Devops/isle-buildkit
• https://github.com/Islandora-Devops/isle-dc