Hi!
I’m new to the forum, so sorry if question is dumb.
Due to constrained server environment I’m trying to deploy Juju in Kubernetes since small cluster is already deployed there. I’ve found Docker page for juju, but I’m not sure how to give it a bite. I’m planning to use Juju as deployment method for Openstack along with MaaS which I should connect to Juju. Docker page contains jujubox (All-in-One), operator and mongodb which I guess are necessary for deployment to work. The latter two don’t contain any description, but I guess they would be more proper for my situation.
So to conclude my problem, I have three questions which may or may help me to achieve my target.
So to begin with, did someone try to deploy Juju in Kubernetes?
I’d also like to know ports which I should open for both Operator and MongoDB, and for outside communication
The third question is about accessing Juju Operator.
Is there a client to access Juju, or should I exec into pod everytime I need to do something?
By client I mean CLI tool, I gues if I’ll be able to deploy Juju, I’ll also be able to deploy GUI.
Hi, @xsenonn. Welcome to the forums!
Architecturally, Juju comprises three components: a client, and “controller”, and a number of juju “agents”.
The client is the thing that you as a human operator interact with most directly. It is installable via a snap, though there are alternate installation methods (there’s another thread on this forum related to installing in a docker container). The client is simply a go binary that knows how to install and interact with controllers in your cloud.
The controller typically runs in a container or virtual machine in the cloud that you are targeting. Among its components are a go binary and a mongodb, but you typically don’t have to worry about the internals. You simply hand your juju client credentials for a cloud (whether it be OpenStack, Kubernetes, MAAS, AWS, etc), and run “juju boostrap <controller_name>.”
You typically won’t have to worry about the juju agents unless you’re troubleshooting. They’re software daemons that run alongside your workloads, reporting back to the Juju controller so that it can keep track of what has been deployed, where.
In your case, you need to install the Juju client either on a local machine that you have access to, or a jump box that has more complete network access to machines in the cloud. You can use that client to then bootstrap a controller in the cloud where you’re going to deploy your applications.
Side note: you might wind up with multiple controllers, and even end up bootstrapping into a cloud that you are managing with Juju!
For example, you might juju boostrap maas ..., then juju deploy openstack-base in order to get your OpenStack cloud running. Then, after adding credentials for your newly created OpenStack cloud, juju boostrap openstack ..., and use that to control applications in your OpenStack cloud.
You can use the juju controllers and juju switch commands to view and move between your “undercloud” and your cloud applications. See the docs for details, and feel free to ask more questions here!