How to Prepare Meals at Scale – Building Application Models in Cisco CloudCenter | Part 3/4
3 min read
Part 1 and Part 2 summarized the basic toolset inside of CloudCenter for multi-cloud application deployment and how to prepare properly. Now let’s get our hands into some real cooking to get a meal with astonishing taste.
Cooking, Designing and Building Services
Be creative every time you cook at home for your family. Even if you keep serving your standard set of dishes, they may taste slightly different each time unless you use ready-made sauce from the supermarket. As a professional chef, your sauce tastes the same every day unless you develop a new version. This is the only way to scale, guarantee constant quality and delegate the creation of it to others.
A service should be as generic as possible. Rather have a basic OS with a specific kernel and basic packages, than build a service for each web server type and version. Also consider the set of libraries and tools you are going to use over time, such as Python libraries, node.js, chef, puppet, and others. Having these libraries in place in the service may shorten the deployment time quite a bit.
When designing a service, it is important not to re-invent the wheel. Carefully check out the existing services in CloudCenter and also other available sources such as this one available on github.
Building the Service is the interesting part of the work. Hopefully by now you have a plan on how to implement the service and what tools and applications you have to install on the system. Depending on your modeling principle, you can do all steps necessary in a single shot or build you scripts incrementally and test each step.
The use of a versioning system (like Git) is highly recommended. Start from an existing working example and modify it to your need. Last but not least, reference files and libraries rather specifically (in terms of versions), as over time the library might change and you want to ensure the deployment stays the same way you designed it.
Service scripts are usually built using shell scripting. Check out the CloudCenter documentation.
Ingredients – Design and Build Images
The foundation for each service is an image. As mentioned multiple times, stick to a low number of images where possible.
Having a bunch of different but similar images is a major problem. Patching and updating will become a huge effort. So don’t go there. Better use an existing image.
The use of existing images is encouraged, even if the image is not a perfect fit and is slightly wrong in terms of installed versions of libraries or settings. These and other dependencies can be adjusted using service scripts during the deployment process. There are many injection points available to modify and control the image and service behavior. Make sure you understand them, we will cover this topic more in depth later.
Keep in mind that images are cloud specific. If you build your own images, you have to make them available in all target clouds for your application.
Creating an image for cloud center follows basically these steps:
- Deploy a base OS (e.g. Ubuntu, CentOS or alike)
- Install the CloudCenter worker agent, if applicable. This allows CloudCenter to control the image in later stages
- Upload the image to the cloud location (e.g. VMware)
- Map the newly created image in CloudCenter (Admin->Infrastructure->Images)
- Create a shell-service and use this in a simple application to test the image. More information on image management can be found in the Documentation
Follow the Process – Lifecycle Actions
CloudCenter offers a variety of points to control the application deployment process.
It’s crucial to understand and be aware of the interaction of these lifecycle actions and the order of execution.
CloudCenter Actions Start
CloudCenter Actions Stop
You don’t need to use all life cycle actions and scripts. As you will see in the following example, using one or the other may be enough.
I’d like to thank sous-chefs Ralf Antweiler and Sebastian Straube who helped a lot in the mise en place for this Blog series.
Authors
