As part of documenting Juju usage in production, it occurs to me that training is an important part of making use of Juju in-house.
What is the process that you use to teach Juju? Are there are a set of steps that you encourage new operations staff to go through in your team? What would the ideal training course look like?
Beginner
Bootstrap to localhost.
Bootstrap a public cloud.
Deploy the cs:ubuntu charm in an empty model
Retrieve a public IP address from a unit
Deploy a bundle (perhaps a deploy a Kubernetes cluster)
Run an action
Use juju ssh to access a unit
Intermediate
Explain what juju switch is and what it does
Where are Juju logs stored? What does juju debug-log do?
Where is the charm youâve deployed stored on a machine in your Juju model?
What is the effect of restarting a Juju daemon process (jujud) on a machine running in your model?
Explain what juju switch is and what it does
Can you explain the terms model, application, unit, machine and relation to someone new to Juju?
Advanced
How is Juju upgraded, and what does an upgrade mean in Juju terms?
A graphical, pedagogical, description of the state machine with a complete description of the different âhooksâ that are fired at each step.
Plus.
Good strategies (example code) on what to put in those hooks as a beginner charmer. This is a key thing, since many beginners will likely copy those patterns for a long time in their own work and subsequent contributions to the charm ecosystem.
The first thing I have people do when learning juju is run âjuju help commandsâ, âjuju help commands | grep thingâ . This immediately exposes the user to the wealth of jujuâs capabilities, shows them how to start navigating juju from the cli and helps them understand how they can figure things out for themselves by grepping for what they are trying to do with juju. I still use this tactic to this day. If I want to know what commands are available for manipulating credentials I might run âjuju help commands | grep credentialsâ.
There are three distinct sets of âHow to use Jujuâ also.
The operator/non programmer perspective. Thing would the be like:
$ juju run-action myapp/0 do-something
$ juju add-unit myapp
$ juju config myapp var=value
⊠etc.
The devops/charm developer perspective. That would be a like:
âHow do I reconfigure myapp using hooks with python?â
âHow do I alter the cloudinit process with juju?â
How do I implement a http relation in the myapp charm?
The juju infrastructure perspective, which would be;
How do I setup/deploy a multiuser juju controllers with candid and letâs encrypt ssl certs?
How do monitor, backup and upgrade my controllers?
All of these perspectives intersect somehow, but could be organized as above perhaps.