Hi,
Thank you for your reply.
if I understood correctly, Juju to deploy from a client workstation (Windows,
Ubuntu or Mac OSX) charms on a Cloud architecture (by SSH). Charm and does
not need to be written as a function of cloud used. The charm describes the
installation, configuration, and relations with other services.
If I am researching and Head Juju is to find a solution to the problems of
our business:
We are the editor of a software suite and would simplify to our customers
install the suite on cloud clients
To do this, we think developing Juju charm that would have charge of the
deployement of our suite, the associated databases and the Apache Service.
Regardless of the architecture that the customer wish.
It's possible ?
Best Regards,
Felane
2014-05-03 17:32 GMT+02:00 Marco Ceppi marco.ce...@canonical.com:
On Tue, Apr 29, 2014 at 6:31 AM, Ilisia Felane felane@gmail.comwrote:
Hi,
I started with Juju, and I look for more information on the architecture
of Juju.
1) Is there a server to fully use Juju? I can not find on the site that
installed a Client. If yes, where can I find a server version of Juju? If
not, how can I integrate the charms that I create?
I'm not sure I understand this question, could you elaborate more? Juju is
installed on the client machine (your computer) and a variety of commands
are used to create new environments in a cloud and deploy charms to that.
Unlike other tools, like Chef, which have a server component and a client
component which are installed seperately, Juju creates the server setup for
you using the client. You simple need to enter the credentials for your
cloud environment and run `juju bootstrap`. At this point you'll have a
juju server (referred to as the bootstrap node) which does the
orchestration for you. Charms can't be run without having a bootstrap node,
they are quite different than existing tools in the space (I'll explain
that in reply to your point number 3).
2) Where can I find additional documentation on the establishment of a
comprehensive architecture Juju? The documents on the website speak only the
configuration for the cloud and the establishment of charms ...
Matt's link is a great start. We're working on bringing the more technical
overview of Juju in to the official docs over the next few weeks.
3) Can I use the recipes created with Chief, but what's the point? What
are the differences between Juju and Chef?
Chef and Juju are solving two different and unique problems. So to answer
your first question, yes you can use Chef recipes inside juju charms. In
essence Juju charms are to juju as chef recipes are to chef. They're the
set of instructions need to manage a service throughout it's lifecycle (for
instance: how do I install, configure, manage, etc this service). But
that's about as close as the similarities get. Juju is all about service
orchestration, a relatively new concept which is naturally the next level
up from configuration management.
So how does Chef and Juju differ? Chef (and Puppet, and Ansible) are all
REALLY good at abstracting away the process of managing a single view of a
machine. Given an outline of a machine Chef will try it's damnedest to make
sure the machine is setup as you've described it and will make sure that
same definition works on Linux as it does Mac OSX as it does Windows. Juju
solves a different problem, I have a set of machines configured, how do I
get them to talk to each other and how do I scale them? In this respect
juju doesn't actually care too much about one individual machine but rather
the services (which are comprised of machines) and how these services
communicate with each other. In order to get that point, where you can have
machines talk to each other, you need to do some level of configuration of
each machine in the service pool. This is one part of the job of a charm.
As such, charms can be written in any language and do anything they need to
in order to put the service in a state that is can then begin talking to
other services in the deployment.
So, if you have chef scripts that can run with chef solo, they can be put
in a charm and the charm can use that for it's logic on how to get the
machine it's living on to look as you described. Same can be said with
Puppet manifests, Ansible playbooks, Salt modules, etc. There are already a
whole suite of tools that solve the configuration management issue so we
want to make sure that you as a charm author can do what you need (and what
makes sense to you) for the service you're deploying. Juju really strives
(and excels) at making sure services can scale, talk, and respond to user
input in a quick, simple, and robust way.
Marco Ceppi
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
