4 ms·

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

by jcastro 15y ago

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 15y ago
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 15y ago
  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.
  - mh- 15y ago
    your comment here should have been the blog post, or at least the condensed version of it that better explains the actual technical benefits. that is cool.
    - marcoceppi 15y ago
      There are several blog posts about deploying with Juju, I think this was just an announcement about the Charm Store going live. There are some posts on http://cloud.ubuntu.com/tag/juju/ http://cloud.ubuntu.com/tag/juju/ and examples at http://juju.ubuntu.com/ http://juju.ubuntu.com/
  - boxein 15y ago
    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 15y ago
      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.

by jcastro 15y ago

amalag 15y ago

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 15y ago
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.
- mh- 15y ago
  your comment here should have been the blog post, or at least the condensed version of it that better explains the actual technical benefits. that is cool.
  - marcoceppi 15y ago
    There are several blog posts about deploying with Juju, I think this was just an announcement about the Charm Store going live. There are some posts on http://cloud.ubuntu.com/tag/juju/ http://cloud.ubuntu.com/tag/juju/ and examples at http://juju.ubuntu.com/ http://juju.ubuntu.com/
- boxein 15y ago
  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 15y ago
    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.