One of juju's strength's is standing up complex deployments as workloads. Frequently, these complex deployments represent infrastructure that also accepts workloads and hosting of service, ala:
- openstack
- docker
- cloudfoundry
Even a simple bootstrapped juju environment in a different substrate could be thought of as a juju deployed system capable of accepting juju workloads.
We are also seeing the emergence of mesh computing infrastructure (the decedendants of Google's Borg):
- mesosphere
- kupernetes
- fleet
- etc
These systems represent a further abstraction from operator, workload, and execution environment. The notion of the machine disappears.
The box and it's counterpart the node linger as skeumorphic vestiges of 20th century, a promised format for operation for installation and interaction (ie provides ssh relationship).
Juju currently has a tight coupling between charms, units and the notion of a machine. For systems such as mesophere, docker or even an existing operational system like another CM managed architecture or a separate juju environment, the machine abstraction fails.
We have talked about the concept of stacks as a collection of services providing a tailored interface. If stacks were to provide the following characteristics to the juju environment, they could provide a useful facade for exposing dynamic capabilities to an existing juju environment.
A stack would need to have the ability to advertise that it provides the capability to deploy workloads to it via juju.
These workload would take the form of stacks or charms to the charm author, but coupled to the workload interface of the providing stack.
Stacks would define how to deploy to them and require a place to execute said behavior.
This would necessitate a change to charms. I've used the 'series' prefix to denote a new kind of workload deployment. Ideally these could find definition as plugins.
ie:
docker/mysql
A charm that launches a mysql docker container and
can manage interelationships within a docker system (ala links) or outside.
mesos/web-app
A generic charm for mesos deployment that takes a uri for an
executable and enables an http interface.
A stack will need exposure back into the juju environment, allowing other charms to orchestrate against it.
Unlike a charms, a stack may dynamically add nested provisions and requirements. A stack may choose to expose these as top level relationships, or they may be accessed by a placement shorthand.
{stack}:{service}:{relationship}
The stack could act as a placement target for workload that matched it workload type.
Likewise, a requirer or provider could relate to services with in a stack by a hierarchical address.
stack:service
A command could create an alias in the currently active environment as a way of managing primacy:
juju alias stackname:servicename servicename
libswarm (docker cluster):
juju deploy cs:stack/libswarm-cluster docker
juju deploy cs:docker/rethink-db --to=docker
juju deploy local:docker/my-app --to=docker
juju alias docker:my-app my-app
juju alias docker:rethink-db rethink-db
juju add-relation rethink-db my-app # knows to use libswarm to link services
juju deploy ./my-other-app
juju add-relation rethink-db my-other-app # knows to do configure restart dance
inception1:
juju bootstrap # 6 box MAAS
juju deploy cs:stack/openstack --to='0,1,3' mycloud
juju deploy --config='bootstrap:true' --to=mycloud cs:stack/juju-env juju
juju alias mycloud:juju cloud
juju deploy --repository=https://local-reg stack/our-app-stack --to=cloud prod_b
juju deploy --repository=https://local-reg --to="3,4,5" stack/our-app-stack prod_a
juju deploy cs:stack/monitoring-love monitoring --to=cloud
juju add-relation prod monitoring
juju add-relation staging monitoring
juju deploy haproxy lb
juju add-relation prod_b haproxy
juju add-relation prod_a haproxy
juju action lb 'group prod_b:10 prod_a:90'
juju action lb 'group prod_b:30 prod_a:60'
inception2:
juju boostrap # bootstrap aws-east1
juju switch env1
juju deploy --config='envid:aws-east1' cs:stack/juju-env aws1
juju deploy cs:stack/libswarm docker --to=aws1
juju alias aws1:docker docker
juju deploy cs:mysql-container mysql --to=docker
juju deploy cs:stack/containerized-cf cf --to=docker
juju alias docker:mysql mysql
juju alias aws1:cf cf
juju add-relationship cf:service-broker mysql:db
juju deploy local:./my-juju-unaware-webapp --to=cf
juju deploy local:./my-aware-webapp --to=cf
juju list-provides docker
mysql:db
workload:docker-container
docker:list-containers
juju list-requires cf
my-aware-webapp: db
juju list-provides cf
my-dump-app: http
workload: cf-app
service-broker: db