Test libcloud 0.14 beta 3 sur GCE, AWS et Rackspace

Depuis la version 0.14 (encore en phase de bêta) il est possible d’utiliser Google Compute Engine. Il existe encore qq bugs que j’essaye d’aider a éliminer :

https://github.com/apache/libcloud/commit/7a04971288791a02c1c335f9d36da2f90d892b5b

Grace a libcloud il est tres facile de creer des machinnes virtuel dans les cloud public. Voila un petit exemple pour GCE, AWS et RackSpace :

def createNodeGce(iGceConex,iAmi, iInstance, iLocation):
 #image = [i for i in iGceConex.list_images() if i.id == iAmi ][0]
 size = [s for s in iGceConex.list_sizes() if s.name == iInstance][0]
 alocation = [s for s in iGceConex.list_locations() if s.name == iLocation][0]
 print("Create server with image : " + str(iAmi) + " and server type : " + str(size) + " and location : " + str(alocation))
 node = iGceConex.create_node(name=GCE_INSTANCE_NAME, image=iAmi, size=size,location=alocation)
 print(str(node))
 return node
def createNodeAws(iAwsConex,iAmi, iInstance):
 image = [i for i in iAwsConex.list_images() if i.id == iAmi ][0]
 size = [s for s in iAwsConex.list_sizes() if s.id == iInstance][0]
 print("Create server with image : " + str(image) + " and server type : " + str(size))
 node = iAwsConex.create_node(name=EC2_INSTANCE_NAME, image=image, size=size,ex_securitygroup=EC2_SECURITY_GROUP,ex_keyname=EC2_KEY_NAME)
 print(str(node))
def createNodeRackSpace(iRackConex,iAmi, iInstance):
 image = [i for i in iRackConex.list_images() if i.name == iAmi ][0]
 size = [s for s in iRackConex.list_sizes() if s.id == iInstance ][0]
 aSshKeyFilePath = "SSH_KEY_PUBLIC"
 print("Create server with image : " + str(image) + " and server type : " + str(size))
 node = iRackConex.create_node(name=RACKSPACE_INSTANCE_NAME, image=image, size=size)

L’exemple complet est disponnible sur github ICI :

https://github.com/charly37/LibCloud014b3Test/blob/master/TestLibCloud.py

Tester sur une machinne Ubuntu 13 sur AWS avec l’instal suivante :

#Install setuptools. Necessaire pour pip
sudo apt-get -y install python-setuptools

#Install GIT. Necessaire pour libcloud DEV
sudo apt-get -y install git

#install PIP
curl -O https://pypi.python.org/packages/source/p/pip/pip-1.4.1.tar.gz
tar xvzf pip-1.4.1.tar.gz
cd pip-1.4.1
sudo python setup.py install

#install libcloud 
sudo pip install git+https://git-wip-us.apache.org/repos/asf/libcloud.git@trunk#egg=apache-libcloud

Voila le resultat avec listing des VMs sur les 3 providers et puis creation d’une VM sur chaque provider avant de lister une nouvelle fois les VMs existente.
ubuntu@domU-12-31-39-09-54-77:~$ python test.py

Create libcloud conex obj
Then list the different provider object (to validate logins)
Listing GCE :
Listing EC2 :
Listing RackSpace :

Then list the different VMs (on each provider)
Listing GCE :
Vms :
[]

Listing EC2 :
Vms :
[<Node: uuid=f8cc89f6b6e061784e37c49fbc28a3917a86acf2, name=TEST, state=0, public_ips=[‘54.196.177.12’], provider=Amazon EC2 …>, <Node: uuid=e81bdb7b32d3fbff0ec745e9dc63cf1d7e5c32bb, name=____AWS_TUNNEL, state=0, public_ips=[‘54.227.255.145’, ‘54.227.255.145’], provider=Amazon EC2 …>, <Node: uuid=d231cd56e5e7f3ffad93eb7d1f0b9445e91199ed, name=____Couchbase Master, state=5, public_ips=[], provider=Amazon EC2 …>]

Listing RackSpace :
Vms :
[<Node: uuid=d6ef246e8a738ac80cdb99e2f162b1ec46f21992, name=Rgrid, state=0, public_ips=[u’2001:4801:7820:0075:55e7:a60b:ff10:acdc’, u’162.209.53.19′], provider=Rackspace Cloud (Next Gen) …>]

Then create nodes

Create server with image : <NodeImage: id=ami-ad184ac4, name=099720109477/ubuntu/images/ebs/ubuntu-saucy-13.10-amd64-server-20131015, driver=Amazon EC2  …> and server type : <NodeSize: id=t1.micro, name=Micro Instance, ram=613 disk=15 bandwidth=None price=0.02 driver=Amazon EC2 …>
<Node: uuid=0c2b1e827325d3605c338aed44eb7d87e2b448b1, name=test, state=3, public_ips=[], provider=Amazon EC2 …>
Create server with image : <NodeImage: id=f70ed7c7-b42e-4d77-83d8-40fa29825b85, name=CentOS 6.4, driver=Rackspace Cloud (Next Gen)  …> and server type : <OpenStackNodeSize: id=3, name=1GB Standard Instance, ram=1024, disk=40, bandwidth=None, price=0.06, driver=Rackspace Cloud (Next Gen), vcpus=1,  …>
Create server with image : centos-6-v20131120 and server type : <NodeSize: id=12907738072351752276, name=n1-standard-1, ram=3840 disk=10 bandwidth=0 price=None driver=Google Compute Engine …> and location : <NodeLocation: id=654410885410918457, name=us-central1-a, country=us, driver=Google Compute Engine>
<Node: uuid=cd805862d414792acd7b7ed8771de3d56ace54ad, name=test, state=0, public_ips=[u’173.255.117.171′], provider=Google Compute Engine …>

Wait few seconds

Then list the different VMs again(on each provider)

Listing GCE :
Vms :
[<Node: uuid=cd805862d414792acd7b7ed8771de3d56ace54ad, name=test, state=0, public_ips=[u’173.255.117.171′], provider=Google Compute Engine …>]

Listing EC2 :
Vms :
[<Node: uuid=f8cc89f6b6e061784e37c49fbc28a3917a86acf2, name=TEST, state=0, public_ips=[‘54.196.177.12’], provider=Amazon EC2 …>, <Node: uuid=e81bdb7b32d3fbff0ec745e9dc63cf1d7e5c32bb, name=____AWS_TUNNEL, state=0, public_ips=[‘54.227.255.145’, ‘54.227.255.145’], provider=Amazon EC2 …>, <Node: uuid=d231cd56e5e7f3ffad93eb7d1f0b9445e91199ed, name=____Couchbase Master, state=5, public_ips=[], provider=Amazon EC2 …>, <Node: uuid=0c2b1e827325d3605c338aed44eb7d87e2b448b1, name=test, state=0, public_ips=[‘50.16.66.112′], provider=Amazon EC2 …>]

Listing RackSpace :
Vms :
[<Node: uuid=a41759d8732fdbddf37a22327d63734bd89647aa, name=test, state=0, public_ips=[u’2001:4801:7819:0074:55e7:a60b:ff10:dc68′, u’166.78.242.86′], provider=Rackspace Cloud (Next Gen) …>, <Node: uuid=d6ef246e8a738ac80cdb99e2f162b1ec46f21992, name=Rgrid, state=0, public_ips=[u’2001:4801:7820:0075:55e7:a60b:ff10:acdc’, u’162.209.53.19′], provider=Rackspace Cloud (Next Gen) …>]
ubuntu@domU-12-31-39-09-54-77:~$

Serveur CentOs 6.4 avec stockage éphémère sur Amazon Web Service

Pour des raisons de portabilité entre Cloud provider j’ai décidé de migrer de l’image “Linux AMI” disponible uniquement sur AWS vers CentOS 6.4 disponible chez tous les Cloud public.

Pendant la migration j’ai cependant constate quelques problèmes avec les disques éphémères de mes instances qui n’été plus accessibles.

Avec la distribution « Linux AMI » et d’autres (par exemple Ubuntu) les disques éphémères sont utilisable dès la création de l’instance :

ubuntu@ip-10-181-140-167:~$ df
 Filesystem     1K-blocks   Used Available Use% Mounted on
 /dev/xvda1       8125880 739816   6966636  10% /
 none                   4      0         4   0% /sys/fs/cgroup
 udev              836600     12    836588   1% /dev
 tmpfs             169208    184    169024   1% /run
 none                5120      0      5120   0% /run/lock
 none              846032      0    846032   0% /run/shm
 none              102400      0    102400   0% /run/user
 /dev/xvdb      153899044 192068 145889352   1% /mnt

Alors qu’ils ne sont pas disponibles sur CentOS :

[root@ip-10-180-141-3 ~]# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/xvde              8256952    649900   7187624   9% /
 tmpfs                   847608         0    847608   0% /dev/shm
 [root@ip-10-180-141-3 ~]# ll

Pour pouvoir utiliser les disques éphémères sur une centOS il faut faire 2 choses !

1/demander à avoir les disques éphémères lors de la création de la VM.

Cela peut se faire dans l’interface graphique lors de la création de la VM (fig) ou alors en ligne de commande lors de la création également.

Ephemere

Dans mon cas j’utilise « libcloud » et il faut donc ajouter l’option « block mapping ». Voilà comment procéder :

node = EC2_Conex.create_node(name=aServerName, image=image, 
size=size,ex_securitygroup=[EC2_SECURITY_GROUP],ex_keyname=EC2_KEY_NAME, 
ex_blockdevicemappings=[{'DeviceName': '/dev/sdb', 'VirtualName': 'ephemeral0'}])

Ensuite il faut attendre que la VM soit créé pour passer à l’étape 2.

J’ai créé 2 VMs pour montrer la différence « avec » et « sans » l’option.

AVEC :

charles@ip-10-164-17-109:~$ ssh -i /Rbox/conf/Rbox_Proto2.pem root@ec2-107-21-170-54.compute-1.amazonaws.com
 Last login: Fri Oct  4 08:58:53 2013 from 10.164.17.109
 [root@ip-10-182-164-253 ~]# fdisk -l

 Disk /dev/xvdf: 160.1 GB, 160104972288 bytes
 255 heads, 63 sectors/track, 19464 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x00000000

 Disk /dev/xvde: 8589 MB, 8589934592 bytes
 255 heads, 63 sectors/track, 1044 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x00000000

Sans

[root@ip-10-28-86-161 ~]# fdisk -l

 Disk /dev/xvde: 8589 MB, 8589934592 bytes
 255 heads, 63 sectors/track, 1044 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x00000000

 [root@ip-10-28-86-161 ~]# exit

La VM créer sans cette options ne pourra jamais utiliser le stockage éphémère et vous pouvez vous arrêter ici…..

La seconde étape permet d’utiliser les disques. En effet il ne sont pas utilisable pour le moment meme sur la machine qui a le disque éphémère :

[root@ip-10-182-164-253 ~]# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/xvde              8256952    650188   7187336   9% /
 tmpfs                   847608         0    847608   0% /dev/shm
 [root@ip-10-182-164-253 ~]#

2/Rendre les disques utilisable

 [root@ip-10-182-164-253 ~]# fdisk -l

 Disk /dev/xvdf: 160.1 GB, 160104972288 bytes
 255 heads, 63 sectors/track, 19464 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x00000000

 Disk /dev/xvde: 8589 MB, 8589934592 bytes
 255 heads, 63 sectors/track, 1044 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x00000000

 [root@ip-10-182-164-253 ~]# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/xvde              8256952    650188   7187336   9% /
 tmpfs                   847608         0    847608   0% /dev/shm
 [root@ip-10-182-164-253 ~]# mkfs -t ext4 /dev/xvdf
 mke2fs 1.41.12 (17-May-2010)
 Filesystem label=
 OS type: Linux
 Block size=4096 (log=2)
 Fragment size=4096 (log=2)
 Stride=0 blocks, Stripe width=0 blocks
 9773056 inodes, 39088128 blocks
 1954406 blocks (5.00%) reserved for the super user
 First data block=0
 Maximum filesystem blocks=4294967296
 1193 block groups
 32768 blocks per group, 32768 fragments per group
 8192 inodes per group
 Superblock backups stored on blocks:
         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
         4096000, 7962624, 11239424, 20480000, 23887872

 Writing inode tables: done
 Creating journal (32768 blocks): done
 Writing superblocks and filesystem accounting information:
 done

 This filesystem will be automatically checked every 34 mounts or
 180 days, whichever comes first.  Use tune2fs -c or -i to override.
 [root@ip-10-182-164-253 ~]#
 [root@ip-10-182-164-253 ~]# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/xvde              8256952    650188   7187336   9% /
 tmpfs                   847608         0    847608   0% /dev/shm
 [root@ip-10-182-164-253 ~]# mkdir /ephemeral0
 [root@ip-10-182-164-253 ~]# echo "/dev/xvdf /ephemeral0 ext4 defaults 1 2" >> /etc/fstab
 [root@ip-10-182-164-253 ~]# mount /ephemeral0
 [root@ip-10-182-164-253 ~]# df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/xvde              8256952    650192   7187332   9% /
 tmpfs                   847608         0    847608   0% /dev/shm
 /dev/xvdf            153899044    191936 145889484   1% /ephemeral0

Et voilà 😉

Resume :

mkfs -t ext4 /dev/xvdf
mkdir /ephemeral0
echo "/dev/xvdf /ephemeral0 ext4 defaults 1 2" >> /etc/fstab
mount /ephemeral0

SSL tunneling Raspbery Pi

on commence par installer le package stunnel4 :

sudo apt-get install stunnel4

Ensuite il faut l activer sinon on aura cette erreur en essayant de le lancer :

pi@raspberrypi ~ $ sudo /etc/init.d/stunnel4 start
SSL tunnels disabled, see /etc/default/stunnel4

donc pour éviter ca on édite le fichier de conf :

sudo vi /etc/default/stunnel4

et on remplace

ENABLED=0

par

ENABLED=1

ensuite on configure stunnel en créant son fichier de conf qui n existe pas par défaut :

sudo vi /etc/stunnel/stunnel.conf

dont voici le contenu

chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside the chroot jail
pid = /stunnel4.pid

client=no
cert=/etc/stunnel/stunnel.pem
debug=3
sslVersion = all
output=/var/log/stunnel4/stunnel.log
[sslssh]
accept=443
connect=localhost:22

ensuite il faut une clé sinon on aura cette erreur au démarrage :

sudo /etc/init.d/stunnel4 start

pour créer la clé :

pi@raspberrypi ~ $ cd /etc/stunnel
pi@raspberrypi /etc/stunnel $ sudo openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem

et enfin on peut le starter

pi@raspberrypi /etc/stunnel $ sudo /etc/init.d/stunnel4 start

et vérifier qu il est bien lance avec

pi@raspberrypi /etc/stunnel $ ps -aux | grep tun
warning: bad ps syntax, perhaps a bogus '-'?
See http://gitorious.org/procps/procps/blobs/master/Documentation/FAQ
stunnel4 20179  0.0  0.3   4400   604 pts/0    S    07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
stunnel4 20180  0.0  0.3   4400   604 pts/0    S    07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
stunnel4 20181  0.0  0.3   4400   604 pts/0    S    07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
stunnel4 20182  0.0  0.3   4400   604 pts/0    S    07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
stunnel4 20183  0.0  0.3   4400   604 pts/0    S    07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf
stunnel4 20184  0.0  0.3   4400   748 ?        Ss   07:54   0:00 /usr/bin/stunnel4 /etc/stunnel/stunnel.conf

Ensuite il faut penser a garder sa clé “stunnel.pem” avec soit pour pouvoir la copier sur le client

Pour configurer le client il faut télécharger putty et stunnel pour Windows. Ensuite in faut installer stunnel et dans le répertoire d installation il faut remplacer la clé “stunnel.pem” par notre clé.

Une fois que la clé est installe il reste plus qu a démarrer stunnel et changer sa config en la remplaçant par :

client = yes
 delay = yes
 [sshtunnel]
 accept = 127.0.0.1:22
 connect = <adresse IP serveur qu on a configurer avant>:443

et on peux ensuite utiliser putty en se connectant a l adresse stunnel : 127.0.0.1:22 et on atterrira sur le serveur distant

Pour AWS EC2 AMI instance

[ec2-user@domU-12-31-39-09-EE-BA stunnel]$ cat stunnel.conf
root = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside the chroot jail
pid = /stunnel4.pid

client=no
cert=/etc/stunnel/stunnel.pem
debug=3
sslVersion = all
output=/var/log/stunnel4/stunnel.log
[sslssh]
accept=443
connect=localhost:22

puis

[ec2-user@domU-12-31-39-09-EE-BA stunnel]$ sudo stunnel stunnel.conf