Installation d'application Ruby on Rails sans connexion internet

Bizarrement, je n'avais jamais trop travaillé sur les applications écrit en rails et par conséquent, je n'avais jamais eu affaire aux désagréments qui vont avec. Bien sûr, je ne parle pas du langage en lui-même ni des frameworks qui vont avec. Non, c'est plutôt dans la gestion des gems avec le fameux utilitaires bundler.

Oui, parce qu'il faut savoir c'est que, si vous avez une connexion internet, ce brave ruby va gérer tout seul ses dépendances et compagnie. Par contre, si vous êtes comme moi dans une DMZ dans laquelle il n'est même pas question d'entendre parler de flux sortant sur un proxy, vous allez vite vous sentir seul.

C'est donc après avoir bien galéré que je me suis dit qu'une petite entrée sur mon blog aurait un double bénéfice (au delà de l'aspect purement narcissique) : me servir de pense bête et vous servir à vous les nombreux lecteurs de ce blog.

Par la suite, nous travaillerons sur l'installation de l'application Kibana (pour faire de la recherche de grosses données dans le nuage, euh, je veux dire, du scoring de big data dans le cloud).

Au début il vous faut quand même une connexion internet

Pour l'installation initiale de votre application, il vous faudra au moins une connexion internet pour commencer. Si vous n'avez pas accès directement à internet, vous pouvez toujours passer par un proxy. Pour cela, il faut exporter la valeur du proxy dans la variable http_proxy :

export http_proxy=http://user:mdp@proxy:port

Une fois ceci fait, vous pouvez lancer le bundle de votre application. Mais vous vous en doutez, avant de le faire il faut installer bundler. A noter que vous devrez installer les packages ruby et rubygems (si vous êtes sous Redhat, ça se fait très rapidement avec la commande yum install ruby rubygems). L'installation de bundler se fait simplement avec la commande suivante :

gem install bundler

Une fois que bundler est installé, nous allons pouvoir maintenant récupérer les gems pour notre application. Prenons le cas de l'application Kibana. Pour se faire, il vous faudra :

• Décompresser votre application ;
• Se rendre dans le répertoire décompressé et lancer la commande suivante :

bundle install

De là, l'ami bundle va se connecter sur internet et récupérer toutes les dépendances dont nous avons besoin.

Création d'un bundle

Maintenant que notre application tourne, nous allons maintenant pouvoir faire un bundle de nos dépendances afin de les recopier sur nos serveurs de production qui n'ont pas du tout de connexion internet (les pauvres ...). L'opération est très simple et se fait avec la commande suivante :

bundle package

Your Gemfile contains path and git blablabla.

Resolving dependencies...

Using rake (10.1.0)

Using daemons (1.1.9)

[...]

Your bundle is complete! blablabla.

Updating files in vendor/cache

De là, l'ami bundle devrait vous faire un répertoire vendor/cache avec les fameux gems à installer.

Installation en production

Il ne vous reste plus qu'à faire un transfert de ce répertoire dans le répertoire de l'application sur vos serveurs de production et de lancer la commande suivante :

bundle install --local

Là, bundle devrait comprendre qu'il faut qu'il utilise le contenu du répertoire vendor/cache. Il ne vous restera plus qu'à prendre un café à ma santé.

Packager NSClient++ sous Windows (64 bits) à l'aide de puppet

Bon, pas la peine d'en rajouter sur le titre, j'ai honte. Mais bon voilà, j'avais commencé à vouloir packager NSClient++ avec l'OS alternatif propriétaire (avec ce plugin), et je me suis rendu compte que le package NSClient++ était réinstallé tout le temps. J'ai donc voulu savoir pourquoi.

En effet, en lançant l'application du catalogue sur mon noeud, j'avais systématiquement ce message :

Notice: /Stage[main]/Nscp/Package[nscp]/ensure: created

Notice: /Stage[main]/Nscp/File[C:\Program Files\NSClient++\nsclient.ini]/content:

Info: /Stage[main]/Nscp/File[C:\Program Files\NSClient++\nsclient.ini]: Filebucketed C:/Program Files/NSClient++/nsclient.ini to main with sum e3daba1

4bc76433649a9c4af706042ac

Notice: /Stage[main]/Nscp/File[C:\Program Files\NSClient++\nsclient.ini]/content: content changed '{md5}e3daba14bc76433649a9c4af706042ac' to '{md5}38b

2bb3dbe8530f33d983ccfd8394628'

Info: /Stage[main]/Nscp/File[C:\Program Files\NSClient++\nsclient.ini]: Scheduling refresh of Service[nscp]

Notice: /Stage[main]/Nscp/Service[nscp]: Triggered 'refresh' from 1 events

Notice: Finished catalog run in 11.64 seconds

En gros, mon package nscp était constamment réinstallé et ce dernier venait également mettre à jour le fichier nsclient.ini. Je me suis donc dit que le package n'avait pas le bon nom et qu'il fallait que je trouve le bon. Après avoir essayé NSClient++, NSClientpp, j'en ai eu marre de chercher et je me suis posé la question de savoir comment avoir le nom de ce fameux package. C'est là que j'ai découvert l'existence de la commande puppet resource package. Ci-dessous un extrait de la sortie de cette commande :

[...]

package { 'NSClient++ (x64)':

  ensure => 'installed',

}

package { 'Puppet Enterprise':

  ensure => 'installed',

}

[...]

J'avais enfin le nom de mon package ('NSClient++ (x64)') et du coup, NSClient arrêtait de s'installer systématiquement et donc, le fichier nsclient.ini n'était plus à mettre à jour. En gros, mon agent n'avait plus rien à faire. Bonne nouvelle donc !

Utilisation de Puppet sous AIX pour la gestion des logicals volumes

Depuis quelques temps, j'ai découvert un nouveau sujet d'amusement : Puppet. Le produit est particulièrement intéressant et j'ai commencé à travailler sur un POC impliquant des agents pour différents OS (AIX, Linux et bien sûr Windows).

C'est à cette occasion que j'ai découvert l'existence de Puppet Forge et notamment l'excellente extension permettant de gérer les volumes groupes de Linux (extension lvm). Suite à ça j'ai voulu disposer de la même chose pour AIX. Au début, j'ai voulu implémenter ça directement dans le module lvm mais devant le travail que ça représentait, j'ai préféré faire quelque chose de spécifique mais surtout de plus simple. Je verrai plus tard pour faire ça comme il faut :)

Cette classe s'utilise sous la forme de module. Il vous faut donc créer un répertoire /etc/puppet/modules/aix avec un sous répertoire manifests:

mkdir -p /etc/puppet/modules/aix/manifests

Créer ensuite le fichier aix/manifests/logical_volume.pp avec le contenu suivant :

# Handle AIX LVM
define aix::logical_volume(
  $mount_point,
  $ensure = "present",
  $vg = "rootvg",
  $size = "",
  $lv_options = "",
  $fs_options = ""
) {

  $lv_name = $title
  $fs_type = "jfs2"

  case $ensure {
    # Clean up the whole chain.
    cleaned: {
        mount { $mount_point: ensure => "unmounted",
                atboot=> false, device => "/dev/$lv_name" } ->
        exec {"/usr/sbin/rmfs /dev/$lv_name ":
            onlyif => "/bin/test -n \"`/usr/sbin/lsfs $mount_point 2> /dev/null`\"",
        }
    }
    # Create the whole FS
    /^(present|created)$/: {
        # Creation du FS avec un nombre de block = 1
        exec {"/usr/sbin/mklv -t$fs_type -y $lv_name $options $vg 1":
            onlyif => "/bin/test ! -b /dev/$lv_name"
        } ->
        exec {"/usr/sbin/crfs -v$fs_type -d $lv_name -m $mount_point $options -A yes -a logname='INLINE'":
            onlyif => "/bin/test -z \"`/usr/sbin/lsfs $mount_point 2> /dev/null`\"",
        } ->
        mount { $mount_point: ensure => "mounted", atboot=> true, device => "/dev/$lv_name" }
        case $size {
            /^(\d+)([KMGT])$/: {
                $size_hash = { "K" => 1, "M" => 1024, "G" => 1048576, "T" => 1073741824 }
                $kilo_size = $1 * $size_hash[$2]
                $block_size = $kilo_size * 2
                exec {"/usr/sbin/chfs -a size=$size $mount_point":
                    onlyif => "/bin/test ! \"`/usr/sbin/lsfs $mount_point | /usr/bin/awk '/$lv_name/ { print \$5 }'`\" = \"$block_size\"",
                    require => Mount[$mount_point]
                }
            }
            /^\s*$/: { }
            default: {
                fail ( 'size is not valid (eg: 1G, 256M, 1T etc.)' )
            }
        }
    }
    default: {
        fail ( 'aix::logical_volume: ensure parameter can only be set to cleaned or present/created' )
    }
  }
}

De là, vous pourrez l'utiliser sous cette forme dans une déclaration de noeud :

node 'machineaix' {
  aix::logical_volume { "test":
      mount_point => "/test",
      size => "1G"
  }
}

Cette merveille a été testé avec succès sous AIX 7.1 et devrait fonctionner sans problème sous AIX 5.3 et 6.1.