Commonly in startups, you probably don't be worry about how your application artefacts are managed to be deployed in a server: compressed files or JAR/WAR files combined with a set of scripts. However, for larger companies that uses not only one or two servers, but a entire pool of machines, it requires some control and organisation to deploy apps. You can handle this case with some automation / configuration management tools like Ansible, Puppet, Chef, of course. But using a set of scripts can be hard to maintain all deployment steps, from artefact update to rollback.
If you distribute your software using a Operational System package manager like YUM (CentOS) or APT (Debian, Ubuntu), your deployment will be easier because these tools handles software changes in a good way. It sounds good, but package binaries is a pain for developers or newer sysadmins that don't have knowledge about how YUM/APT works. It requires creation of one or a lot of configuration files to be updated and when you have multiple artefacts probably packaging them will be a nightmare.
Here enter fpm-cookery, a Ruby gem responsible to package artefacts based on recipes, much easy to use. It will be your swiss knife for anything that you need to package, from common binaries not distributed in RPM/DEB formats to programming languages from source, compiling when needed.
3. $ whoami
• Fireman / Problem Solver / Programmer since 2000
• Ruby, Python, Golang, Java, C#, Classic ASP, PHP,
Coldfusion, Erlang and others
• DevOps Engineer @ Moip
4. In the beginning…
• How software was updated on old times?
• Tarballs (zip, tar.gz)
• Transfer via FTP / SSH / Ctrl+c Ctrl+v
• Common problems
• A not-so maintained README explaining how to update it
• Manual steps
• Lack of rastreability (who updated glibc?)
5. … to some years ago
• Package Manager concept
• Dependency Resolution
• Filesystem Standardisation
• File Integrity
• Central Package Repository
• Transaction History
6. … and today
• How software is updated today?
• Configuration Management tool
• Package Manager
12. Packaging is good
• When your business grow, your software will too
• From monolith app to microservices
• You need to adopt a standard workflow to distribute
software recognisable to all ops people
• Package managers like APT/YUM are well-known
• Deploy-friendly
• You can use your custom solution, of course
13. Packaging is good
• Configuration Management recipes that manages
tarballs tends to be complex:
• Manual dependency resolution
• Can be a nightmare if requires compilation
• Black magic recipes
14. Packaging is good
• Configuration Management recipes have support
for main package management tools in-a-box as a
module
• Recipes much more simpler
23. fpm-cookery for the rescue
• https://github.com/bernd/fpm-cookery
• Bernd Ahlers
• A tool to build and package anything
• Abstraction to famous Jordan Sissel fpm gem
24. fpm-cookery for the rescue
• Package is created with a recipe
• class MyPackage < FPM::Cookery::Recipe
• Two methods to implement:
• build
• install
• It’s Ruby, man. Enjoy :)
25. fpm-cookery for the rescue
• Download tarball with precompiled binaries
• Download and compile from source code
• Build dependency resolution with Chef gem
• One recipe to package .rpm, .deb and.dmi
• Helpers to create package filesystem as you need
26. fpm-cookery Live Demo
• How I package a tarball containing binaries?
• How I package a tarball with source code?
27. “It sounds good. But how I can package
mundane things like web apps without need to
write recipe for all of them?”
– I, maybe you
28. Gordon: agnostic packaging
• https://github.com/salizzar/
gordon
• Very oppiniated tool to
package web / standalone
apps
• No need to recipe, just use it
as a CLI
29. Gordon: agnostic packaging
• Some years ago I wrote a code generator to create Debian
package build files
• Code generator to create skeletons is great, but after some time
you will get a problem when you need to change something
• Some examples:
• change init scripts to use systemd
• add / remove files to project
• Apps will change, developers without knowledge of
standards will break it
30. Gordon: agnostic packaging
• Foreman to generate init files
• systemd
• Other formats can be included
• inittab
• supervisord
• upstart
• Set of fpm-cookery generic recipes that handles most cases of
web / standalone apps
31. Gordon: agnostic packaging
• Generic recipes are based on years of application packaging
following good conventions
• Operational System standards (Debian, Red Hat / CentOS)
• Nginx / Apache / Tomcat / Jetty directories
• Application run using their non-interactive shell user or
application server user (Tomcat)
• Dedicated log directory
• /var/run issue