I have a set of containers that currently run in Mesos and I want to move them to Rancher. But first I need to verify functional parity between Mesos and Rancher.
I’m clicking around in the API “pages” in the UI trying to figure out what I can and cannot do with containers.
I can start a “container” using the API, but it looks like individual containers can’t be scaled. But I started a container inside a service, using the UI, and seems this container can be scaled. Is this by design? Or did I accidentally create a container incorrectly using the API?
Please, advise me on the best way to add and manage containers using the Rancher API.
Note: assume that these containers are true micro services, meaning they don’t have run time hard dependencies on the host or other containers.
First, to be clear, everything that you can do in the UI, you can do in the API.
From the infrastructure/containers page, you can start “stand alone” containers. These you can not scale.
From the applications page, you can start services in your stack(s). In the service parameters is information about which image that each container instance should run. These services are scalable, determining the number of containers they will run.
To take full advantage of all of Rancher’s features you want to use the services approach.
Notice however that with the recent addition of selector links, you can now start single containers, and have them join a service, based on what labels they have.
Ok using the API, from what I can tell, I need to create a “Stack” which is an “environment” in the API. And I add the “environment” to the project, which is an Environment in the UI. Then I need to create a service and add it to the environment. I think I see how this will work…and I know you are planning to align the API names with the UI.
And just to be sure I’m not missing something, in the API, the term “Applicaiton” is not used, and doesn’t directly map to anything in the UI. It’s just the title for a page that is a “view” of the stacks in the UI.
Also, tell me more about these “selector links”. I don’t see them in the API structures. Would I just set io.rancher.project.name and io.rancher.project_service.name to a make the single container a service part of the application?
You’ve grasped the API/UI discrepancies I see (and they’re planning on fixing them, as you say). I guess your right about “Application”, but I’ll leave it open for @vincent to comment on that.
Have you considered using rancher-compose? Not sure what constraints are, and working with the API is certainly feasible, it may prove easier to get going with rancher-compose. From there it’s very natural with stacks/environments and services etc. The limitation is mainly that you can only work with a single stack at a time in your compose files.
We’ll definitely use rancher-compose for human interaction at the CLI, for our more complicated stacks. But for automated processes, I’m not a fan of shell-ing out to run CLI commands, then parsing the printed text. (Yuk!)
Having said that, for this exercise I may cheat and use rancher-compose to set up the stacks, then just use the API to manage the services. Especially, if the API will be changing soon.
I have a semi-related question, I’ll tag it on here but if a mod feels it should be posted by itself, please feel free to break it away from this topic or let me know.
I’m starting to do some tests with Rancher, and initially I understood that a “full application” would go into a single stack… I now understand that this may not be the best practice, as in contrast to the Microservices tutorial (which builds a single stack for web+db+glusterfs), the ELK demo suggests adding a “es” stack for elasticsearch and then other stack for logstash tier, etc…
The documentation on stacks/services isnt very clear IMO, but I do understand that stacks can communicate with each other (even considering the fact that there is only 1 LB per physical host, and it serve multiple stacks…)
Anyways, is there a limitation between stacks/services that I should be on the lookout for? What is a way to determine the breakup between multiple stacks…
I understnad a simple 3-service app like the wordpress+pxc+gluster example is fine on 1 stack, but complex structures with multiple tiers, multiple DBs, etc might make sense to have more stacks…
Is this discussed somewhere? I’d like to read more abt it too! thanks!
UI “Environment” (in the upper-right dropdown) == group of physical resources == API “project”
UI “Stack” (in the Applications tab) => group of services => API “environment”
…We will someday fix that in a /v2.
“Application” is just the name of the tab, it will make more sense once you have Catalog as a 2nd thing in there besides Stacks. “Infrastructure” is grouped around physical resources (hosts), “Applications” and “Stacks” around logical resources (services).
@RVN_BR the grouping of services into stacks is more or less up to you. You initially couldn’t link across stacks but that was added added; the main limitation as @kaos said is rancher-compose works with a single stack at a time. And the new Catalog uses compose and creates applications as their own new stack. A decent guideline is to group related services that form some kind of logical grouping that you might want to upgrade together into a stack.
thanks!