This is a sentence i oft hear from developers. And it's true. On there Workstation everything works fine. But on the Servers...
Everyone loves new projects!
If you start a project without paying attention to the requirements it will fail. But there are a lot of people doing it this way...
In this example i will create a project with 3 VMs. One for the Web Application One for the Caching And one for the Database
First we create a new Rex project with the „rexify“ command.
Then we create a file called „box.yml“ describing our infrastructure. It is also possible to create the Rex/Boxes within the Rexfile with perl code. But if we use a YAML file it is later easier to switch – for example – our development to Amazon by only changing the YAML file.
Here you'll see it a little bit larger. The „setup“ option tells Rex witch task it should run on the newly created VM to provision it.
This is the Rexfile. First we enable all the new features and then we set the authentication information for the VMs. Every Box you download from box.rexify.org has a default password „box“ for the root user.
Then we load the Box module and set the YAML file.
And create a task that will create all the VMs described in the box.yml file.
With the function boxes „init“ we advice Rex to create the VMs
We also create the 3 tasks to setup the VMs.
Creating the VMs
A community Module directory for Rex
It is possible to download modules and its dependencies from modules.rexify.org with the rexify command
The command will download and extract the module into the „lib“ folder.
After the download we can use the Module in our Rexfile
Here we set the root directory for perlbrew.
If we want to build our own perl we need to install some build dependencies first.
Then we can install perlbrew and a custom perl.
There is also a MySQL module for Rex on modules.rexify.org. In this task we just create a new schema and a new user.
Deploying applications can be done in many different ways. These are 3 ways Rex::Apache::Deploy supports
First we create a deploy task. But if we write it that way, the deployment task will run on our local machine.
So we first need to define some groups and add servers to the group.
For Rex/Boxes we can use the function „list_boxes“ to get a list of all available VMs.
After we have defined our group we can add the group to a task. So this task will now run on every server of the „www“ group.
Then we use Rex::Apache::Deploy with a special paramter „Git“. This tells the module that we want to use Git based deployments.
At last there is always a need to write configuration files. For example to configure the database or other things.
There is a file() function to upload files to the remote system. It is also possible to use templates. This will generate the content for a file on the fly.
There is one special things with templates. If the template name starts with „@“ it will look at the __DATA__ section of the Rexfile to find the template and not on the filesystem. So you can add your templates directly to the Rexfile.
Transcript of "From Test to Live with Rex"
From Test to Live with Rex
Who am I?• Jan Gehring• Working @ inovex as System Architect• Planing, Building and Operating of Linux Infrastructures• Mostly Web- and Mailcluster• Perl since 1998
Who am I?• Jan Gehring• Working @ inovex as System Architect• Planing, Building and Operating of Linux Infrastructures• Mostly Web- and Mailcluster• Perl since 1998• @jfried83• http://github.com/krimdomu
A new Project• 2 Ways to start o We just start without thinking... o We ask for the requirements
A new Project• 2 Ways to start o We just start without thinking... o We ask for the requirements ● Software Architecture ● Requirements regarding Perl- or Module Versions ● OS ● Do we need to support High Availbility or Cluster Solutions ● And much more...
There is more...• Environments• Manage services o start o stop o Edit runlevels• Working with files / Config-Management o Templates• User Management• Filesystem Operations• Harddrive Operations• ...• http://rexify.org/api