Applying best practices in deploying your app on the Cloud is no easy task. Not even a WordPress powered CMS. Needless to say, with the complexity of today’s technologies, if nothing else, it’s worth it to try and, at least, stay in the same technological ballpark as your competition; your users will thank you for it. And you can do that by setting up WordPress on the Cloud, using Cycleops. No code required!
A no-code approach to build your stack
Best practices are a tough nut to crack. That’s why we’ve created a no-code approach to building your stack, using Cycleops. WordPress will be up and running on your newly created servers, using best practices, in a repeatable and reliable manner. The days when your dev server used different components from your staging server, will become a thing of the past.
Accessible, no matter your role
Whether, at the time of writing this article, we don’t really offer fine-grained role management, it’s on our road map. Once out, you’ll be able to use Cycleops with different access rights for different roles and types of jobs. That includes:
- Administrator
- Developer or team of developers
- DevOps Engineer
- Operator
Do it once, use it globally as many times as you need
A good thing that comes out of a “templated”, no-code approach like that is that you can create your stack template and use it as many times as you need, creating the exact same infrastructure every time. This is of great importance if you need to create a robust workflow for developers and administrators; especially so, if you need to give your DevOps Engineer the opportunity to incorporate customer feedback into the process. The self-service DevOps approach offered with Cycleops is the way to go.
Standardize your stack and deployment process
Standardizing your stack and deployment process, not only enables you to create robust and reliable applications and workflows. It also helps you standardize and implement DevOps without breaking a sweat; not to mention, it allows you to put everything into perspective, with a continuous integration and continuous delivery or continuous deployment pipeline.
In other words, stack and deployment standardization solve the problems of urgency and speed in communication among different teams. And, of course, it uses our knowledge of best practices, built into the process, so that you don’t have to worry about proper implementation. Long gone are the days when your processes kept failing you, creating delays and costly downtime. But, that’s not all!
Create as many flavors for your stacks as you need
The power of templating your infrastructure isn’t only in standardization. You can also create different flavors, as you go and as you need them, for different implementations. You no longer have to create your list of services from scratch, every time something changes. Each flavor can be used reliably and repeatedly without problems, and you can keep your old ones for compatibility, until obsolescence knocks on the door. And, still, you’ll be able to modify them with new services and keep working on them, without having to scratch them.
What about redeployments? Can you fix problems?
Redeployments are easy as one-two-three. You need only find your stack template and run the deployment as you normally would. Our Ansible-powered automated process will find and fix all existing components, replacing what’s needed and adding any new ones in the process. And, while you can use the terminal to follow the process, you won’t really need to intervene on any of the steps. So, how do you do all that?
Creating the stack
As you’d guess, it’s not a single step process. Nevertheless, it doesn’t take the fun out of it. First, you need to compose your stack. Then, you can create some new services and add them to your stack, as needed.
Compose your stack
This is also a two-step process. Depending on your needs, you first need to select your Operating System services and then go on and tie in your Platform services.
1. Select OS services
Your OS services are the base of your infrastructure. It’s where your stack will be deployed and where your entire application will be installed and configured. Selecting your OS services, you can also provide for:
- Security options
- A Hostname for your server (you’ll need that to connect to it, later)
2. Select platform services
Depending on the type of application you want to install, you’ll probably need a few different services to be running on the server’s OS before you can go on and install it. This includes:
- A Database service (e.g. an SQL-based or a NoSQL Document-based DB)
- A Docker engine to wrap around everything, which will make it greatly easier to manage, in the long run
Then, all you have to do is save this structure, adding it to your stack templates list. At this point, you can also add hosts, as needed.
Here’s an example of a service list for a WordPress deployment, below. Keep in mind, the order of definition matters, if you want to avoid problems in the production environment:
- git-wordmissive
- nginx-wordpress
- php-fpm-wordpress
- mysql57-wordpress
- selinux-per-defaults
- Hostnamepress
But, let’s see how these services came to be.
Create new Services: The ingredients in a Stack
Now that your stack template is ready, you need to create some new services. Once you’ve created them, you can go back and add these to your stack template, as required. Service units are essentially the ingredients in a stack. As we’re accustomed to, by now, this is a two step process:
1. Select a service unit (e.g. load balancing using HAProxy)
Let’s say you’re trying to perform some load balancing, using HAProxy. Create a service with HAProxy. In the next step, you’ll be able to configure quite a few different things, to your needs. These include:
- Versions
- Log rotate
- Stats
- Functional information
- Management
- Performance
- Default configuration
- Timeouts
- Front end configuration
- Back end configuration
- Save → Added to service list
2. Manage service configuration
Service configuration isn’t really mandatory. Oftentimes, you can go with the default settings and save it to your list of service units. But, in the grand scheme of things, you can keep tabs on everything before using it, by glancing at which stacks it’s already being used in. Most of the time, it makes sense for you to use the same service unit on your dev, staging and production servers for each project.
Deploying the WordPress setup
Deploying your freshly templated WordPress setup is a two and a half step process, in that the third step (the half step) is actually automated. Let’s see how it works.
1. Adding your web server host or host group to the stack
To deploy your WordPress stack, you first need to create a web server to host it. If you already have one, you can go ahead and add it to your stack. Otherwise, you’ll need to create a new one, to your needs. You can either create and add a single web server as a host, or decentralize your infrastructure and create different hosts — ideally, bundled into a host group — for different assets, increasing the security, compliance and robustness of your infrastructure. But, how do you add a new host?
2. Add hosts
While there is some complexity to creating the right types of hosts for your application, it’s a quite straightforward process to do in Cycleops, if you know what you need. Let’s take the example of a private host, which is probably more difficult to wrap one’s mind around.
Creating a new private host for your database
Creating a host is easy as pie. But, making it a private host will, as expected, make it unavailable to the broader network of hosts and services. This is to be expected, otherwise your security would be compromised. Now, creating a private host on a public network won’t be very easy. As you try to register it, registration will keep failing. To be able to pull this through, you need to identify it as a jump host. But, first, you need to know which type of environment it will be used in.
Match host resource to an environment in Cycleops
Depending on the type of environment — e.g. dev, stage, production — creating your hosts may need a slightly different approach. That is, mostly because you may need more or less of your assets to be public, in each case. Once that decision has been made, you can go on and create your private host for your database.
What is a jump host or bastion host?
A jump host — also known as a bastion host — is an intermediate, special-purpose server on your network. It is specifically designed and configured to withstand attacks. This type of server — namely, bastion — is named by analogy to the military fortification. A jump host is actually available to your public network. And that takes care of the failed registration problem, altogether.
Register host: Use as jump host
You can register your jump host by checking the “Use as jump host” option. Then, you need to register it with an SSH key or a strong password. Once your jump host is registered, you’ll eventually need to use it. Now, to access a private host, you would typically set up and use a VPN connection. And, this would be the preferred method to access private hosts on a public network. Thankfully, a jump host removes that requirement from the equation.
Registering the private host for the database using a jump host
As mentioned, for a private host to be available to a public network, it needs to go through a jump host. That’s a simple checkbox to check while creating it in Cycleops; there’s nothing to it, really. However, the jump host also needs to use a public IP address, to allow outbound access to the private host, as a secure, intermediary asset.
After that, you can create your private host, as you normally would, and register it to the network.
Registering a public web host to use with the database
A web host is routinely created for nearly all implementations on the Cloud. It’s also an asset that borderlines a commodity. Creating one is automated on all platforms that offer web host services. In Cycleops, it’s as easy as setting up an IP address and selecting the environment it will be registered to. A simple login to the provider, then, completes the creation process.
Once all public and private hosts are created and registered to your environment, you’re good to go. Next step, stack deployment!
3. Ansible automates the setup process
At this point, you’re practically done with the entire infrastructure. Our Ansible-powered engine will deploy your stack automatically, only where needed. To explain, existing infrastructure will be omitted from the deployment process, unless it needs to be repaired. This single-click application deployment is a timesaver, especially in re-deployments. So, what is left to do? Well, the deployment, itself!
Monitor the process using the terminal
You need to trust the process. So, especially if this is the first time you’re using the automated deployment process in Cycleops, you can fire up the terminal and follow the steps, as everything gets set up on the server. Ansible will first install the OS services you selected and continue with the Platform services, according to the service list you compiled to create your stack template. Before each service unit is installed, the engine will look for any dependencies and install them first, to ensure that all the required components are properly connected to each other. And, that’s pretty much all there is to it!
View your reports
You can visit the Jobs tab on the Reports section to see if any problems occurred during deployment; verify there are not any issues you need to address before jumping into production. But, of course, that’s not the only possible use for these reports.
Get insights into daily resource management
You can use the reports available in the Reports section to get occasional or regular insights into your daily resource management. These insights will help your entire team, including your DevOps engineer, to promptly make improvements and fix problems before they become real usability issues for your customers. And that’s the real purpose of a self-service DevOps platform, like Cycleops. That is, to intrinsically reinforce your workflows, leveraging the power of CI/CD. Needless to say, of course, customer feedback is another extremely useful way to make improvements.
Optimize your operations
Reports are also a great tool to identify problems in your processes; especially where hand-offs are involved. By identifying these problems, you can go back and revise problematic processes, making improvements that will minimize or remove glitches, entirely. The DevOps engineer will be able to set actionable goals towards these improvements; and prioritize them, according to urgency, efficiently communicating what needs to be done to the entire product development team.
Reuse in different environments
Another great advantage of stack standardization is that you can reuse a stack as many times as you need, invariably getting the same results. This kind of uniformity is key, especially if you need to create the right conditions for asset isolation. And this can prove exceptionally useful if you need to deploy failover infrastructures, for increased reliability, ensuring your customers’ job continuity.
Finalizing your self-service WordPress deployment
If you’re used to manual work in structuring and deploying infrastructures, this will come as a pleasant surprise to you. Finalizing your self-service WordPress deployment involves nothing more than firing up your browser and verifying everything works as expected. Typically — unless any issues occurred during deployment — you won’t need to do anything by yourself. Your new, contained environment will be instantly accessible, in all its grandeur, implemented with the most current best practices. That ensures enhanced security, updated compliance, increased reliability, and improved robustness, ready for your customers to enjoy and happily pay for.