In this post I just want to share a couple of SVG tips regarding inline SVG. My inspiration for this series of articles is that I was trying to update a web site with a bunch of inline SVG, and I ran into a couple of issues. Some of the SVGs I found looked fine as stand-alone images, but looked pretty crappy when inlined in the HTML. In the past when I’ve hit such issues, I usually just found a different SVG or created my own, but I was using a lot of SGV for images like the Microsoft PowerApps logo. I didn’t want to use a different images, and I don’t really want to produce my own version of the image, so I needed to learn a bit more about SVG under the hood, and it turns out it wasn’t that hard to figure out.
Fun with Inline SVG
Inline SVG is one of those things that I’ve used for years, but never quite taken the time to understand. It’s easy enough to just copy it into an HTML page and hack it to bend it to my will. I’m very fond of inline SVG for icons in web applications for a few reasons
- It is relatively inexpensive, meaning you can create some pretty icons for image buttons without a heavy download and it compresses well.
- It scales to any size (except tiny, and what qualifies as tiny depends on how complex your image is, as in you’re not going to have a lot of detail in a pixel?).
- You can modify it dynamically with CSS or JavaScript.
I’ve seen some alternatives proposed by developers over the years to scratch some of the same itch, but not anything I like as much as inline SVG, for instance:
- Custom font-based solutions like Font Awesome: the problem with these, for me, is that many enterprises block custom font downloads in group policy, because of very real security concerns.
- Emoticons – size-wise, these are certainly appealing, you get some nice images for only a character each, and they’re built into the browser, no image download required. But you have a limited set of icons to choose from, and if they don’t have what you need, you find yourself using an image that doesn’t quite match the action of your button, and that can understandably confuse your users. And historically, different browsers used different characters for the same icon, as in they got ahead of the spec. And ultimately, to make everybody happy, the spec often ended up using either character for that image, which is messy.
So I’ll stick with inline SVG, and given that it’s well past time I dug a little deeper into understanding them. This blog post is my attempt to get started with that.
So now that we’re settled on SVG, let’s take a look at some:
How’s About we add a Scaling Policy, eh?
In this post, we’re going to add a scaling policy to our WordPress auto scaling group.
I read somewhere that all AWS VMs should be launched in an auto scaling group, and at the time that seemed fairly eccentric to me. But after having done my Bastion host template, I agree with that statement wholeheartedly. I don’t recall ever saying I’d like to stand up a server, but if it dies, I want it to stay dead. Generally, you’re standing up a server so it will be available, listening for requests, and sending responses. You don’t know when the request might come, but whenever it comes you want this server to be ready for it.
By itself, an auto scaling group is just a wrapper for one or more VMs that makes them self healing. And who doesn’t like self healing hosts? That said, if you really want high availability, and you expect a load on the servers that is not entirely predictable (and how many servers have an entirely predictable load), then an auto scaling group by itself isn’t enough. You also need to apply a scaling policy to it, so it can provide on demand capacity, which is a central theme in cloud computing. That’s what we’re going to do now.
And Finally, a WordPress Cluster using CloudFormation in AWS
Ok, let’s do this thing! In this post I’m going to be adding a WordPress Auto Scaling Group spread across two availability zones, and an Application Load balancer to accept connections on port 80 and direct traffic to the Auto Scaling Group. Both will be added to the CloudFormation template I started in my last blog post.
Provision a MariaDB RDS Database Instance with CloudFormation in AWS
I’m now 5 posts into this series (and 5 months in), and I’m finally ready to start talking about provisioning my workload, i.e. WordPress. I’ve laid out a rough outline for this, and it’s clearly too much for a single blog post, so I’m going to split it into 3 posts, which I’ll try to publish in the next 3 weeks or so (rather than 3 months, as I’ve been pacing myself until now). After all, I’ve spent twice as much time (in terms of months, not man hours) writing this series as I spent building and launching my blog on AWS. So the next three posts will be:
- Provision a MariaDB RDS Database Instance with CloudFormation in AWS (this post)
- And Finally, a WordPress Cluster using CloudFormation in AWS
- How’s About we add a Scaling Policy, eh?
This post and the last one will be relatively brief, but the middle post will be substantial enough to justify splitting it up. So let’s get started.
Adding a VPC Endpoint for S3 to our VPC Using CloudFormation in AWS
In this post we’re going to modify our existing VPC CloudFormation template and add a VPC Endpoint for S3 to it. I’ll also walk you through a reasonable process to update an existing CloudFormation template.
Add a NAT Instance to our VPC with CloudFormation in AWS
In this post we’re going to talk about how to provision a NAT (Network Address Translation) Instance from scratch, using AWS Linux 2 and CloudFormation. We’re going to provision an auto-healing NAT, meaning an instance launched by an auto-scaling group with a desired capacity of 1, so if our instance crashes the auto-scaling group with terminate it for us and spin up a new one. This is much like the auto-healing Bastion Host I provisioned in a previous post, Provision a Bastion Host to our VPC with CloudFormation. So the CloudFormation template for this NAT Instance is very similar to the Bastion Host template, and this post will focus only on the differences.
Linux Hardening for your Bastion Host
This post is going to provide a brief description of basic Linux hardening for the Bastion Host I created using CloudFormation in my last post. Really it’s hardening 101 for any Linux host, but this kind of information is surprisingly hard to find on the Internet. For instance, I read a bunch of posts that say don’t run services you don’t need, but with no practical advice on how to implement that (like how to figure out what services are running on a typical Linux box, or which specific ones I might want to stop and why). The absolute best post I’ve seen on the subject is 40 Linux Server Hardening Security Tips [2019 edition]. I didn’t actually find this post until after I’d worked through the things I’m going to implement in this post, but it covered them all and a whole lot more, so you could just go there and skip this post, however, it’s pretty complex and hard to follow in some parts, and I’m going to provide a simple explanation for some simple hardening, so you might want to stick around.
Add a Bastion Host to our VPC with CloudFormation in AWS
What is a bastion host? It’s sometimes called a jump box, or in days gone by a sacrificial lamb. Technically, it’s just a machine that is directly exposed to the Internet. In general, you don’t want all of your machines directly exposed to the Internet. So you take one box and expose it through SSH to the outside world (or RDP if it’s a Windows box). If you need to administer a more private instance, you SSH into the bastion and from there you can SSH into the private instance (which doesn’t accept SSH connections from outside of your network) to do your administration task. So you two-hop into your network (jump box) and you assume the direct exposure to the Internet means you may get compromised at some point (sacrificial lamb).
So in this post, we’re going to look at a CloudFormation template for adding a Bastion Host to a VPC. We’re going to deploy our bastion host to an auto-scaling group, not so much for the purpose of high availability but rather for some measure of auto-healing. If the box goes south and stops responding, the auto-scaling group will kill it and bring up a new fresh instance.
Provisioning a VPC with CloudFormation in AWS
This post is about a detailed examination of a CloudFormation template for provisioning a Virtual Private Cloud (VPC) in Amazon AWS. It is the first of what will be a series of posts that talk about Infrastructure as Code, revolving around trying to accomplish some particular thing. In particular, I’m moving my blog (this blog) to AWS from a shared hosting provider, and my experiences doing that is what this series will be about.
I have some specific goals in moving my blog, like my current service is a bit slower than I would like, and also less reliable (only 2 nines of availability), so I was looking to upgrade either way. Looking at the next step up in shared hosting, it would cost about twice as much as I’m currently spending (around $400/year), so I would ideally like to come up with something on AWS that isn’t much more than that, but with improved reliability and maybe speed. I have no idea starting out if I can actually meet any of these goals.