Your SlideShare is downloading. ×
From Test to Live with Rex
Nächste SlideShare
Wird geladen in ...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

From Test to Live with Rex

1,049
views

Published on

Published in: Technologie

0 Kommentare
3 Gefällt mir
Statistiken
Notizen
  • Hinterlassen Sie den ersten Kommentar

Keine Downloads
Views
Gesamtviews
1,049
Bei Slideshare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
14
Kommentare
0
Gefällt mir
3
Einbettungen 0
No embeds

Inhalte melden
Als unangemessen gemeldet Als unangemessen melden
Als unangemessen melden

Wählen Sie Ihren Grund, warum Sie diese Präsentation als unangemessen melden.

Löschen
No notes for slide
  • 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

    • 1. From Test to Live with Rex
    • 2. Who am I?• Jan Gehring• Working @ inovex as System Architect• Planing, Building and Operating of Linux Infrastructures• Mostly Web- and Mailcluster• Perl since 1998
    • 3. 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
    • 4. Well, for me it works...
    • 5. Fail early - Fail hard
    • 6. Rex – Whats that?• Rex is for "Remote Execution"• Automating• Server Orchestration• Confiuration Management• Deployments
    • 7. Rex - History• Project starts in 2010• Was developed for Softwaredeployments• Actively maintained and extended
    • 8. Philosophy• Getting Things Done o Fast o Reliable and Reproducible• Compatibility breach = Bug
    • 9. Philosophie• Getting Things Done o Fast o Reliable and Reproducible• Compatibility breach = Bug• Feature Flags
    • 10. Yeah, a new project!
    • 11. A new project• 2 Ways to start
    • 12. Ein neues Projekt• 2 Ways to start o We just start without thinking...
    • 13. http://www.terminus-notfallmedizin.de/blog/
    • 14. A new Project• 2 Ways to start o We just start without thinking... o We ask for the requirements
    • 15. 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...
    • 16. The Development Environment
    • 17. The Development Environment• Normaly virtual• Setup as close as possible to production• Rex/Boxes for fast VM deployments• Rex to provision and deploy the VMs and later the Hardwarefor
    • 18. Basics• Make = Makefile• Rex = Rexfile• Based on tasks• SSH• Supports Key, Agent and Password authentication• Protocol independant• There is also a HTTP Transport Protocol
    • 19. The Beginning
    • 20. Prepare the System• Example Project o Webserver o Memcache o Database
    • 21. The Development Environment
    • 22. The Development Environment
    • 23. The Development Environment
    • 24. The Development Environment
    • 25. The Development Environment
    • 26. The Development Environment
    • 27. The Development Environment
    • 28. The Development Environment
    • 29. bash# rex box
    • 30. modules.rexify.org
    • 31. The Development Environment
    • 32. The Development Environment
    • 33. The Development Environment
    • 34. The Development Environment
    • 35. The Development Environment
    • 36. The Development Environment
    • 37. The Development Environment
    • 38. The Development Environment
    • 39. The Development Environment
    • 40. The Development Environment
    • 41. The Development Environment
    • 42. The Development Environment
    • 43. The Development Environment
    • 44. 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
    • 45. Deployments
    • 46. Deployments• With Git• With a paket manager (like dpkg, rpm)• With Symlinks
    • 47. Deployments• With Git• With a paket manager (like dpkg, rpm)• With Symlinks• Rex::Apache::Deploy
    • 48. App Deployments
    • 49. App Deployments
    • 50. App Deployments
    • 51. App Deployments
    • 52. App Deployments
    • 53. App Deployments
    • 54. App Deployments bash# rex deploy --commit=abcd1234
    • 55. App Deployments
    • 56. App Deployments
    • 57. App Deployments
    • 58. App Deployments
    • 59. App Deployments
    • 60. App Deployments
    • 61. App Deployments
    • 62. Environments
    • 63. Environmentsbash# rex -E live deploy --commit=abcd1234
    • 64. Thanks for listening!● http://rexify.org/● http://modules.rexify.org/● http://box.rexify.org/

    ×