begin with Juju

[Ilisia Felane]

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.ceppi at canonical.com>:

> On Tue, Apr 29, 2014 at 6:31 AM, Ilisia Felane <felane.ili at gmail.com>wrote:
>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140505/bc3ad21c/attachment.html>