instructions with docker desktop on windows

[laurentopia]

Open a terminal from the location where the generated docker-compose.yml file is located. on windows a terminal is CMD Run 'docker-compose up' command to start Feniks. typing that returns an error because the yml isn't executable is that terminal something inside docker desktop?

[djskinner]

I agree. Some of the templates come with their own load balancers etc. IMO it would be better if the catalog entries tried to do a little less as presumably we all have different requirements when it comes to exposing ports. For example I use a global load balancer service so it is not helpful say the Registry catalog entry tries to do the job of exposing its services to the public network.

[sshipway]

Or, if you're going to bind, make the port number a template variable that defaults to a sensible value so that people can change it if necessary.

In the future, when the templating language is extended to allow if/then/else syntax, we'll be able to have sections switched on and off

[EugenMayer]

i fully second your point @ColtonProvias, this was the reason i remade @sshipway registry catalog catalog, removing the lb binding on the hosts port (and even the nginx for ssl termination). You can compare them both, the one and the new one to see if this difference really matter - i think it does, but thats just my opinion.

I think way to many catalogs are doing this "fat stack", blocking themselfs to be installable at the same time just to have the better "out of the box" feeling when installing them solo.

Using a central load balancer like described here by the rancher devs you can handle all this cases very convenient, graphically. I think the rancher core devs just missed the chance to either pre-configure such a lb on installation, or make one a default ( deletable ) or at least make this a guideline in the catalog documentations. Neither of this has been done yet, thats very sad, since thats such a great concept already technically so.

So i would go further then the upper proposal: a) not only not bind public ports with included lb - do never include a lb for routing purposes or ssl termination. b) Do not include nginx for ssl termination, since lb can do this much more convinient in rancher. c) Do not include nginx if you have a simple pass_proxy configuration without anything else to offer d) Do not offer own db-containers, if the catalog application is not making heavy use of it - since this wastes resources way to hard. Instead use the questions with type "service". This is the most arguable point, thus i would limit this case to "only apply if your application is an infrastructural app", do not do this with actual business applications (since they might to be moved, scaled, whatever as a "unit)

Do build catalogs so they are self-containing, while routing should be handled by the rancher admin, and heavy duty databases can be offered "centralized"

The current registry catalog basically does not hold on moste of those - and the good thing is, you can do it without it by having even less work. For me this fork was conceptually, to see, why @sshipway has chosen this approach, in the end, i cannot really understand it ( for now ).

@sshipway could you explain your motivation? This would be an interesting insight to understand, what reasons you have to build it that way - or the other.

[sshipway]

@EugenMayer - I can see your points; in particular, having separate database containers is an interesting idea, as the template requiring them could simply select from a Service type selector.

As to why I used the approach in the Registry template - it was several reasons.

• I wanted a single, all-in-one template; there were also very few other templates available at that time so no use of external databases
• Using nginx as a cert offloader was because the same cert needs to be available to other parts of the system, and also it automatically generates a self-signed cert if necessary. This is not possible with the Rancher load balancer.
• On our system, we have many Hosts, and so use targetted load balancers to access services. Hence the need for a load balancer frontend, though I parameterised the selection of which ports to expose.
• When I started on this, the templating was limited with no conditionals (there still are not) and no way to have service selection or certificate selection I knew of. Also, template upgrades would break/remove any additional services added to the Stack after template deployment; hence it had to be self-contained

Were I to recreate the template now, then using an external database service rather than one in the stack itself would be a definite possibility. Using the Letsencrypt service rather than self-generating certs would be an idea as well. Building for our environment, I'd use labels that trigger links in Traefik instead of using a separate load balancer container. If the templating language were extended to allow conditionals, then I'd let people pick sections to turn off and on...

The problem is that being all things to all people is difficult, if not impossible. I set up the stack as a standalone as we use it; the idea was that people would take this and customise to fit their own requirements, rather than everyone using it exactly as it is. The Community Catalogue does not have any detailed guidelines one how Stacks should be designed; and so I see it as more a set of examples than definitive setups. I copy the templates to our own local Catalogue and modify them to our taste rather than use them in their vanilla form.

While having 'fat stacks' like the registry one (that try to be completely self-contained) is a problem for one reason, having 'slim stacks' (with the minimal configuration requiring other services to be added subsequently) has a different set of problems. Rancher can make their choice as to which they recommend...

[pcornelissen]

Why is the issue not fixed already? It seems to be a small change (documentation of the changes would be more than the fix itself) Should I give it a try and create a PR?

[EugenMayer]

@pcornelissen i think main reasons are the general PR acceptance speed of the community repo.. one of the reasons i run https://github.com/EugenMayer/docker-rancher-extra-catalogs .. i do not run the portus catalog with a lot of the fixes mentioned there anymore, since i found it worse in any point then sonatype nexus and do no longer want to keep up with the crazy workflow and stack of portus - maintaining the stack if was most probably the most annoying part of all catalogs i have ever created.

Nevertheless, back to topic, try a pr, the mentioned stuff here def. works in production, i ran it for more then 6 months