A suggested conversion to Docker Compose

[tlberglund]

I confess to not being a fan of the cp-all-in-one image for two reasons:

• I think it is even less likely than the rest of the Docker images to be properly maintained (I might be wrong about this)
• Before long, recipes will require other images to generate data or perform other support functions (I am probably not wrong about this)

So I have suggested a docker-compose.yaml file in lieu of the pull of the all-in-one, but having done that, I think this first recipe is starting to look really heavyweight. I would be discouraged looking at it, even with the awesome copy button you've implemented. What would you think of a system in which each recipe had a GitHub repo to clone, or in lieu of that, a ZIP file of project starter materials created as a part of the build? "Clone this and it just works," plus an explanation of the core components, is not the vision you started out with, but having dug into this first recipe, I want to ask the question. :)

[ybyzek]

I have no context for the broader conversation, so I'm jumping in (and out) to address :

I think it is even less likely than the rest of the Docker images to be properly maintained (I might be wrong about this)

I created and maintain cp-all-in-one (and cp-all-in-one-cloud). It is used in the CP quickstart, so it's in fact THE most reliable docker-compose file in all of cp-docker-images repo.

[MichaelDrogalis]

Thanks Tim! A few things:

1. I am actually also not a fan of cp-all-in-one, but for a different reason than reliability [thank you for keeping it up to date @ybyzek :)] For me, it's overkill in terms of the number of components that it launches. I agree that over time, the images each recipe needs will likely diverge. I think what's tricky here is the funnel tracking. If we have N ways to get the platform for N recipes, we'll need to figure out how to catch it N times in the funnel. I'm not sure how to do that.

2. I do think that we need a "clone this" or "download this" button. There is certainly a class of person who just wants the project up and running as fast as possible. I debated for a while how to get this done. I ruled out a Git repository per recipe because it would be really hard to maintain. We'd either need to clone all of the recipes into the Jekyll repo whenever we want to work on it (hard because of all the classic problems of having N repos for N microservices), or do something like submodules (traditionally a problematic solution, too). I think what we eventually want is a way to download a ZIP with the files. That will take some work to get right, and can be left out of the MVP.

3. While I absolutely think we need (2), I think there's huge value in teaching this stuff step by step. One of the biggest obstacles to learning a new piece of tech is wondering why all the pieces are there and how they fit together. Working through the build stages of the project is, IMO, one of the best ways to sell a developer on the soundness of what you're offering.

Let's face F2F when you're back!

[tlberglund]

@ybyzek That was rude of me. I apologize. So it's the only one that is likely to work all the time, but you know I still prefer Docker Compose. :)

[tlberglund]

@MichaelDrogalis I think we can close this. I'm not sure if I misunderstood the setup step when I opened this or if you changed things (and I do not care to look at history and find out which!), but the current recipes are doing things the way I like. So I'm good now. :)