

Why the Juju Charm Store Will Change the Way You Use Ubuntu Server - bkerensa
http://www.jorgecastro.org/2012/04/03/the-juju-charm-store-will-change-the-way-you-use-ubuntu-server/

======
jiggy2011
Ok, so this is a system for deploying an appliance type setup on your server
possibly comprised of several packages?

This would certainly be useful to me. Earlier this week I attempted to setup
of a Linux mailserver from scratch using
postfix,dovecot,spamassasin,clamav,sasl etc.

Wow, what a pain in the ass that was, trying to get all the pieces to talk to
each other correctly and trying to think of possible security holes.

Most of the help online was either lengthy manuals that were pretty difficult
to digest or somebody posting a tutorial basically saying "run these commands
and paste this into your config".

Not really ideal.

What I really want to do is:

sudo apt-get install a-working-mail-server-with-sensible-defaults

~~~
lunarscape
I'm not looking forward to setting up my first Linux mail server next week.
Any tips for a fellow noob? There's so much information and so many guides out
there I don't know where to begin.

Debain/Ubuntu have a tasksel for a mail server but I haven't tried it yet.
(<https://help.ubuntu.com/community/Tasksel>) > sudo tasksel install mail-
server

I plan on trying some other semi-automated installers like iRedMail
(<http://www.iredmail.org/>) in a VM first.

~~~
flyt
Advice from a long-time sysadmin? Don't.

Use Sendgrid, MailGun, or some other managed email provider and let them deal
with the headaches of running mail servers. It's seriously not an industry you
want to try and understand or deal with. Setup an account, pay the service
usage fees, and know that you're saving yourself a lot of headaches.

All of these services now have good APIs, callback hooks, and statistics to
help you track the behavior of your mail traffic without having to write your
own parsing pipeline.

Trade money for time when appropriate. Believe me that the time involved to
deploy, run, secure, and maintain a flexible and stable mail infrastructure
really isn't worth the time better used building a good application.

------
luriel
For those that were asking about real systems built with Go.

Canonical used Go to build the backend for the Juju Charm Store:
[https://plus.google.com/107994348420168435683/posts/fdMcwvCq...](https://plus.google.com/107994348420168435683/posts/fdMcwvCqX4D)

------
mydnite
This bloody rocks with devil's horns.

Seriously, just the other day I had to install package A from source but first
I had to install repo B to download it and install language X to install it as
that was what the build script used. The guys who I manage are probably sick
of me threatening to write something exactly like juju.

I'm going to investigate juju further but if juju can determine the path of
least build dependencies that would also be great i.e. if there are two build
scripts, one bash and the other language X, it chooses bash as you do not have
language X installed.

It would also help if each project offered a link to a tar of their latest
stable version so wget could be used instead of repo B.

I like using the systems tools first before installing other tools.

------
justauser
A few questions maybe some of you already know. What's the "instance" that is
spun up...an LXC container? Also, is this only for Server or will also be
available on the desktop Ubuntu? Cloud only or is this also for local use?

~~~
marcoceppi
Containers spun up depend on the provider, so if you deploy to Amazon it's
going to spin up an AWS instance. However, if you're deploying to an Open
Stack provider it all depends on the Open Stack configuration. Juju doesn't
quite care what the provider does with regards to virtualization software.

However, for development you can setup a "local" provider
([http://askubuntu.com/questions/65359/how-do-i-configure-
juju...](http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-
local-usage)) and deploy to your own machine using LXC. This makes development
quick and affordable and makes it easy to test drive Juju without needing to
use a cloud provider.

------
dysoco
I can't understand what is this exactly for. It's a collection of scripts that
let you easily develop you'r web applications in the cloud ?

Like, it helps you set up a Heroku or Google App Engine Application ?

Also, can I use it in another distro/Ubuntu desktop ?

~~~
marcoceppi
It's more service orchestration. So it's a collection of charms to deploy
services in to the cloud. Heroku and Google App Engine are more PaaS Platform
as a Service, Juju more designed to deploy to Cloud providers like Amazon,
Open Stack, and bare metal.

As for different distros Ubuntu is the only distro that Juju has been tested
on, though Juju is all Python so it likely wouldn't take much to port and
maintain Juju to other Linux distributions. As for the charms most all are
reliant on apt-get so Charms for different distributions that used other
package management software, then charms would need to be updated to use those
instead.

------
aphexairlines
A package manager whose packages are all install scripts that depend on
packages from explicitly-specified repositories for a lower-level package
manager. Somehow I feel like this must have been tried already before -- maybe
in the RPM side of the tracks, or zero-install, or klik?

~~~
marcoceppi
This does more than just package installation, it operates at a higher level.
A service may require several packages that need to be installed, configured,
then configured to work with each other. All of that is captured in a charm
giving you a way to easily deploy a service. So capture your start to finish
setup for any service you use in a charm and you can no deploy, and scale that
service, using Juju.

~~~
vidarh
All of which is possible by creating a package for existing package managers.
It's how I tend to manage services: I build packages that depend on the other
packages I need, and that uses post-install hooks to orchestrate the
connections between various services, or replaces config files.

The level of support for cleanly handling things like replacing config files
vary between package managers, but I've done this easily enough with both dpkg
and rpm.

~~~
marcoceppi
Sure, you can use dpkg to orchestrate connections between services on the same
machine, but last I checked dpkg isn't aware of other machines running other
services and orchestrating the connections between those. Service
orchestration between machines is something Juju excels at. It's really server
and service orchestration abstracted so that you don't have to worry about
what machine is where and connected to who. Juju maintains those relations for
you, so it's really more like apt for the cloud.

------
zobzu
And then some people just use no-nonsense packaging systems. Like ArchLinux's
pacman.

I bet you can write a PKGBUILD for, lets say, zookeeper, including the config
_you_ want faster than it takes to deploy juju (which will use the configs
_it_ wants)

~~~
jcastro
I fear you didn't read the article, does pacman autoprovision the OS on the
cloud for you and deploy it so the service is ready to use?

We're not talking about installing packages on your computer, we're talking
about deploying services on a cloud.

~~~
amalag
I didn't get that till you mentioned it. Article talks about deploying to a
cloud, but no details. I think the packaging of apt is great, but I don't
understand how the cloud deployment fits in.

~~~
jcastro
So pretend it's like apt, but for the cloud.

Instead of deploying a lamp server onto one machine you deploy the service you
want to your datacenter. This can either be EC2, your openstack cloud, or
local machines.

Let's say you want to deploy a scaleable mediawiki at work:

    
    
        juju deploy haproxy 
        juju deploy mediawiki
        juju deploy mysql
        juju add-relation haproxy mediawiki
        juju add-relation mysql mediawiki
    

And then you have a load balancer, a mediawiki instance, and a mysql instance.
You point your DNS to the haproxy instance, and you're ready to go.

2 months later your wiki becomes way popular. Since you're on the cloud you're
totally elastic, so you can go "juju add-unit mediawiki" and you've got
another mediawiki node load balancing. Or do "juju add-unit n=10 mediawiki"
and have 10 nodes ready to go.

If you're on AWS, each of those deploys fires up an instance. Same on
OpenStack. If you're on bare metal the Ubuntu orchestra server on your network
will turn on machines and install/provision them to do the equivalent.

~~~
boxein
What does "add-relation" do, in terms of what happens on the machine? Do
different charms need to be coded with explicit relation types?

Like could I simply switch postgres for mysql in your example and have it
work, or does mediawiki specifically need a relation to a mysql?

~~~
marcoceppi
Charms require different interfaces, so it depends on the charm. In this case
mediawiki has two interfaces, a db (via MySQL) and a db-slave (for MySQL Slave
configuration). When you add relations hooks fire on both charms, MySQL
creates a username, password, database, and all other basic tasks to make a
database work for an application, then passes that information to the
mediawiki installation. From there Mediawiki charm db-relation hook fires to
make sure Media wiki has all of this information in the right configuration
files, install the basic MySQL structure for mediawiki, and several other
tasks needed to make sure Mediawiki is installed.

On the flip side, adding a relation to haproxy, additional hooks fire in each
charm. Mediawiki tells haproxy the address and port it's running on and
haproxy hooks take care to ensure it's in the loadbalancer configuration.

What's excellent about these relationships is as you scale mediawiki to meet
demand (juju add-unit mediawiki) all of this relation data stays in tact. So
each additional unit will automatically fire the proper db hooks and
loadbalancer hooks making sure every unit is setup exactly like the previous
(in the case of MySQL, they'll be sharing the same MySQL database but it will
skip re-installing the db for every unit) and HAProxy will loadbalance between
each unit.

Same happens when you juju remote-unit mediawiki all the relavent hooks fire
and each unit is removed from HAProxy.

------
minikomi
Seems like this a popular idea lately! People striving for simplicity can only
be a good thing. Also check out <https://github.com/j2labs/quickness> (from
the guy who made the equally interesting brubeck python framework).

------
kinleyd
Awesome. And not a moment too soon! It's been a bummer trying to get the
latest application versions via PPA and other methods.

------
ilaksh
I want something like this that is compatible with OSX and Ubuntu somehow.

~~~
SpamapS
Juju is written entirely in python (though a rewrite in Go is underway). In
theory it will work fine on OS X, but there are a couple of challenges to
making that happen:

* Juju is python, but links to the python zookeeper bindings which are C, so one needs something like homebrew to install Zookeeper. * Juju does sometimes make assumptions about Ubuntu specific stuff. We need some brave OS X users to try it out start reporting bugs so we can find out where these are and build tests around it (A good start would be if somebody wanted to donate an OS X machine to run the test suite on).

