If you’re leveraging container technology and using Kubernetes to orchestrate those containers, you’ll know that building and operationalizing an enterprise-grade Kubernetes services isn’t easy. In areas such as security, networking, multi-tenancy, and persistence, container orchestrators are still maturing. Complementary tools to maintain, scale, monitor, and self-heal are also lagging.
Many of you know that Clearpath partnered with Amazon Web Services starting in early 2013. We did this because our customers were already using the AWS platform, asking us for integration assistance, and pushing the envelope of hybrid cloud. Prior to our partnership with AWS, Clearpath delivered managed cloud services through our managed services division, Clearpath hosting. Clearpath hosting - a sister company to Clearpath Solutions Group, was founded in 2008 and originally launched as a private cloud computing service provider, with bolt on managed services for clients hosted in our cloud. In June 2013, Clearpath hosting was renamed to Clearpath Cloud Services (CCS), a division of Clearpath. CCS now provides managed services on the Amazon Web Services platform as well as our own private label VMware vCloud environment. We also deliver comprehensive managed services through our Clearpath Select platform – which is run out of CCS.
A common problem with a very simple solution. Let’s say that you have an IAM user that you’ve created, and you want to provide that user read-only access to an S3 bucket. An example of this that may be common is for those vendors, such as Newvem, that request programmatic access to your billing data.
Amazon Web Services provides a very robust permissions and policy management system through IAM, or Identity and Access Management. One step further that a corporate administrator can go to help protect some of their most restricted accounts.
Configuring AWS Auto Scaling for WordPressIn previous posts, we covered the basics of Amazon Web Services, Preparing AWS Services to support our sample WordPress workload, and Installing WordPress in AWS with ElastiCache and S3/Glacier backups. In this post we’ll look at how to configure an AWS Auto Scaling group of WordPress servers that respond dynamically to the load placed on them by creating new EC2 instances on demand, or spinning down unnecessary instances during low demand to save on operational expenses. Auto Scaling uses AWS Cloud Watch to monitor AWS components and responds to alarm metrics (CPU utilization, number of connections, etc.).
Preparing Amazon Web Services (AWS) for an Auto-Scaling WordPress Site
In my last article I covered the basics of Amazon Web Services (AWS). Now it’s time for some hands-on configuration. The example I’ll be working with in the next few posts is a WordPress based site. I’ll leverage a bunch of services within AWS to support my site – Route 53 for DNS, RDS (MySQL as a Service), Elastic Load Balancers in front of auto-scaling EC2 instances (monitored by CloudWatch), ElastiCache, Simple Storage Services (S3), and CloudFront. As you can see, this setup will be very different from the shared hosting or VPS server you might be on today. Taking advantage of these different AWS services lets me scale much easier (and automatically) than just installing everything on a single server.