DEV Community: Sydney Schreckengost

Getting Started with goreleaser

Sydney Schreckengost — Wed, 09 Sep 2020 06:26:29 +0000

One of the best parts of Go is that you can get a single binary for a given platform that can then be deployed without much fuss. Of course, this simplicity exposes another issue - doing all those builds is maybe a little finicky and it's hard to make a cross-platform way to do all of them at once, and then you have to release them on GitHub, and it's, ugh, a mess.

I started using goreleaser for my newest project goad, a load-testing tool that I tried to mimic as much of the interface of curl as possible.

It's a good system, I think, though it does have a few peculiarities that might limit it for a narrow range of uses, but we'll get into that later.

Installing goreleaser

Since it's written in Go, goreleaser is distributed as a single binary, so we have a few options for installation.

MacOS

brew install goreleaser/tap/goreleaser

MacOS/Linux

brew install goreleaser

This may be an out of date version, according to the documentation.

Linux

goreleaser is also available as a .deb or .rpm package for whatever distribution you might be on.

Manually

This option works for everything. Go to the releases page for goreleaser and download the appropriate file for your system. Extract it, and place the goreleaser binary (or goreleaser.exe on Windows) somewhere in your PATH.

Initializing goreleaser

Once you've installed goreleaser, you need to initialize it for each project you want to use it on.

Navigate to a project you want to manage using goreleaser, and run

goreleaser init

After this, you will have a file called .goreleaser.yml. This gives us a basic configuration. This will only do GitHub releases, but it does them really cleanly, and it gives us a skeleton to flesh out later.

Adding a GitHub token

Next, we need to give goreleaser a GitHub token to use to access our release uploads. You can create a new token here if you're signed in. You'll need to give it the "repo" permissions. Name the token something useful (like goreleaser, etc), and copy the value you're given. Make sure you don't lose this, because once this value stops being displayed, you can't get it again.

Now, however it works for your environment, add this token value to your environment variables with the name GITHUB_TOKEN. On a temporary basis on Linux or MacOS, you can use export GITHUB_TOKEN=token_string from your command line.

Enable go modules

goreleaser really expects you to be using modules, which were introduced in Go 1.11, and are a default in Go 1.13 on. You may need to run export GO111MODULE=on to do this.

If your project isn't already using them, be sure to initialize the module system using go mod init. This will generate a go.mod and go.sum file. Make sure these are committed to your repo!

Clean up your repo

By default, goreleaser will stop if the git repo is anything other than strictly clean - that means no untracked files, no differences in tracked files. The first few times you do this, you will probably need to add things to your .gitignore.

Tag the release

Goreleaser uses semver for versioning, so make sure your version tags are in line with that. It will fail if you are not following semver!

Just need to run

git tag x.y.z

to complete tagging.

Run goreleaser

From here, we can run goreleaser as a command, and it will build the project, update our releases on GitHub. That's it! We now have our releases completely automated!

Goreleaser's limitations

Some people may not like that it requires semver. I know there are some cases where semver is possible but at best a hack.
If you're using older Go versions, you may not want to switch your code to a newer Go that supports modules. While code should Just Work, that's not always guaranteed.
There are lots of options, and you may overwhelm yourself.

Overall, I've been liking goreleaser. It's made one of my biggest loves of Go even easier to tag advantage of, and it's highly configurable, support homebrew formulas, Docker, and plenty more. If you're in charge of a Go project, definitely check it out!

The Platypus

Sydney Schreckengost — Fri, 10 May 2019 22:45:04 +0000

I'm usually an "evolution over revolution" sort when it comes to systems. I don't like make big sweeping changes - they tend to break things, they tend to have a really big "blast radius", and so on.

But evolutionary systems tend to have the same problems that natural evolution has.

Sometimes, evolution creates a platypus.

Look at it. Just-- Just look at it. Its existence is a mystery - it has a bill; it lays eggs; it swims around; it has poisonous claws. And it's a mammal. None of those things make any sort of sense. But somehow, somewhere, those things made it when tons of other species didn't. At some point, the environment was such a way that a platypus was better suited to survival than other species, or at least not so bad that it killed them off.

When you work on an evolving system, you will eventually find a system that you just stare at blankly, nod your head, and wander off, because its very existence makes no sense.

This is a platypus system. No matter how much we try to understand why it exists, we never really will. It probably does things that no other system of its kind does, and we're not sure why; maybe it's a mail system that also plays chess, and no one quite understands why.

So what should we do with these types of systems? Look, your guess is as good as mine. I'm fine trying to make them extinct. Mammals shouldn't have bills, and an HTTP server should't have a roguelike in the logs.

DevOps is Culture, Not Cargo

Sydney Schreckengost — Wed, 02 Jan 2019 06:27:12 +0000

"Hey, we need start doing this thing I read about." Some of you have probably heard that at some point. Depending on who was talking to you, it can usually be one of two reactions: "This is just great! We can finally make some real improvements!" or "This is just great. We have another stupid thing to add to our graveyard of half-thoughts."

One of the hardest sets of lessons to learn is around selecting tooling; knowing how to make the best use of your toolbox, and when it's time to invest in a new tool, and how to push for the right (or better) tooling, can be difficult.

The Right Tool for the Right Job

For most problems, there are multiple ways of solving it. Selecting the right tool is important - selecting the wrong tool means you're going to be slower, less effective, and you're going to end up with a worse product. Selecting the right tool for your problem is a well-studied problem, and your methodologies will vary from team to team.

What a lot of people miss is the core question: what's the right problem to solve? This is the most important question to ask, through every step of a process as complex as software design. If you solve the wrong problem perfectly, you've still solved the wrong problem, and you haven't made any real progress; solve the right problem in a minimal way, and you can bootstrap that into something bigger and better.

When you're looking at a problem, start by stepping back and understanding why it's a problem; from there, keep working your way back, and eventually you'll find the real problem you're trying to solve.

For example, some time ago I was asked to figure out how to make a certain process able to be deployed without incurring any downtime. This is a large process, and while I knew what problem I was trying to solve on the surface - making this process work through deployments. By digging deeper, I was able to look at the real problem: requiring a complete restart in order to make changes to this process meant that making changes happened at a glacial pace, because it could only be restarted during off hours.

Not only did this question help me make better decisions on this project, but it has informed my decision-making moving forward; when I have to make a choice in the midst of a project, I am able to make the best decisions moving forward in a general sense.

What Should We Aim For?

When it comes to DevOps, our tooling doesn't matter so much as understanding what our goals are.

I tend to break the general goals for doing DevOps into three large goals:

Reduce risk
Increase velocity
Reduce toil

All of these intertwine heavily; a lot of things that reduce toil reduce risk; a lot of things that increase velocity reduce toil, and so on.

Reduce Risk

It's 4:58 on Friday afternoon, and the developers have a change to make before the weekend. What do we do here? If we don't push, the devs get mad because they're being held back; if we do push and it fails, we may have just thrown away a weekend for everyone who has to fix it.

Part of what we should be doing is our risk; if a deployment needs to happen at 4:58 on a Friday afternoon, we want to know it will work. There are multiple ways of doing this, but the important thing is this: when we look at the problem of how to handle a deployment at 4:58 on a Friday afternoon, what we're looking at is how to make something less risky. Whether we make the software itself less risky, or the deployment process, or our environment, our real end goals are the same.

Increase Velocity

A developer has spent a week implementing a feature; now, it needs to be integrated into the main branch and deployed. Sometimes, this is easy; sometimes, it can take as long, or even longer, as the actual development.

What can we do to make this process faster? What can we to do completely eliminate the need to spend extra time mushing codebases back together after a divergence? What can be done to make it so that our developers can work faster and more effectively?

Reduce Toil

Every day at 9 AM, you have to restart some service or it will fail. If you don't, your entire infrastructure may fail. If you get sick, or forget to do it, or even just get busy at that exact moment, congrats - you're service is down. Even though it's only 2 minutes a day, it adds up, and the context switching can be brutal. It's busywork. It's toil.

When we reduce the amount of work we need to do in order to do something, we are multiplying our effort; now, we don't have to handle this, we don't have to watch the clock, we don't have to touch it at all. This does a few things for us - when we have fewer things to worry about, we don't have to spend time on them, and we don't feel as exhausted.

We can do this in two ways - removing things that don't need to be done (for example, is the service that needs to be restarted every morning broken? Let's fix it, removing the need to do it at all) and automating what's left.

Culture Over Cargo

So what does real DevOps look like? It's not about using certain tools, it's about asking the questions to make the best decisions to help us reduce risk, increase velocity, and reduce toil.

When we are able to ask these questions and really focus on what matters to making things better, not only do we get to start making products better, faster, but we're less frustrated, we're more reliable, and we can start making the right tool choices even in new circumstances. Tooling isn't what matters when it comes down to it -- knowing where you want to be is.

Building a super cheap transcoder using AWS Lambda

Sydney Schreckengost — Tue, 18 Dec 2018 03:41:49 +0000

Have you ever looked at the price of Amazon's Elastic Transcoder? If you haven't I'll spare you the lookup - it's 3 cents (USD) per minute of video transcoded, if the video is considered "HD". If you have a handful of videos, or you need a lot of flexibility, Elastic Transcoder is pretty cool.

Just one problem - if that's not your use case, Elastic Transcoder can get really expensive. For example, the company I work for processes hundreds of thousands of videos every month, and our needs are very simple - we need to turn a specific type of video into a different specific type of video. This is all we need to do, nothing more and nothing less.

Using Elastic Transcoder, our average monthly bill is high enough to really worry about. While there's no reason not to use the right tool for the job, Elastic Transcoder is overkill for our needs.

After this is done, we'll have a usable, cheap transcoder that we can use. While this does have some limitations, it is still very cost-effective for what it's good for, and understanding this can help understand a lot of really interesting aspects of using S3 and Lambda.

Creating our Lambda function

First, we need to create the Lambda function that we will be using. Log in to AWS, and navigate to Lambda. Click Create Function and create your function. Any language with the ability to call system commands should work fine, though I used Go here because, well, I like it. It's that simple, it doesn't provide a major advantage here.

Name your transcoder, select a language, and create a custom role - if you're not familiar with AWS, this part might get confusing. Something like this should be right for your custom role, if you're looking to get started:



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:GetBucketAcl",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::testBucketName",
                "arn:aws:s3:::testBucketName/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:HeadBucket",
            "Resource": "*"
        }
    ]
}

In the above example, note that you do need both testBucketName and testBucketName/* - one set of the policies is for the bucket itself, the other is the files themselves.

Coding our function

After we've created the function, we need to tell it how to operate. This will vary from language to language, but the general gist is like this:

Download the existing file from S3. The filename and bucket are sent in as part of a an S3 Event in most cases, depending on the library used. As a side note on this, because of the way Lambda works, make sure you have a unique identifier for the video, or you can end up with weird errors. Go on, ask me how I know.
Transcode using ffmpeg - we'll make use of a newer feature to make this simple and portable across any function we might need ffmpeg for. For now, just expect to use /opt/ffmpeg/ffmpeg.
Upload the video to S3.

That's really about it. This will vary from language to language, but AWS fortunately provides pretty usable documentation for this.

Setting up S3 events

Now that we've written our function, the last major thing we need to do is set up S3 to actually send events to Lambda.

Go to the S3 bucket you want to use, and click "Properties", and under "Advanced", click "Events". Now click "Add Notification", and select the object actions that should trigger a transcode (most likely "All Object Create Events").

If there are specific folders you want to include, that can go into prefix; if you are looking for a specific extension, set that in the suffix. Click the dropdown for Send To: and select "Lambda Function". Another dropdown will be created; in here, select the function you created previously.

Creating a layer

Layers are .zip files that are included in the filesystem of a Lambda function. In this case, we are using a statically compiled (that is, it doesn't require anything outside the binary, generally speaking) version of ffmpeg. You can find the one I used here: https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-amd64-static.tar.xz. Extract this, and you should get an ffmpeg directory; add this to a zip file.

Go to your Lambda function, and under the code part at the top of a tree, click "Layers".

Click "Add Layers" and upload the zip file containing ffmpeg. Attach it to the function, and you're done.

Done!

Mostly, at least. Some minor changes to make here and there once it's up, and it can take a little while to figure out the right way to do this in a given language.

When a video gets uploaded, it will be sent to the Lambda function, which will then transcode it and upload it.

This project was designed as part of a way to reduce costs, so let's take a look at that aspect.

A 10-minute video in this setup takes about 105 seconds to transcode. With Lambda, we can give it more RAM to work with, and for longer or higher resolution videos we absolutely do need more; I have our current configuration set to 1280MB.

If our transcoder takes 1280MB and 105 seconds, we can easily calculate our cost to transcode a 10-minute video:

$0.00001667 * (1280/1024) gives us our cost to run the function for a second. This works out to ~$0.000021 per second. Multiplying this by 105, the run-time, gives us a figure of $0.0022. Keep in mind, that with Elastic Transcoder, a 10-minute video would be $0.30. This means that our transcoder, running on Lambda, can provide a greater than 99% discount over Elastic Transcoder.

This does have some limitations:

This will work much better on shorter videos; due to the run time limitation on Lambda, I doubt anything over 45 minutes to an hour is worth transcoding this way.
Longer videos will require more RAM, so the savings do drop a little bit - but even with the RAM maxed out to 4GB, it's still 97+% cheaper than Elastic Transcoder.
It is not very flexible - though this can be overcome with a little creativity.

For our needs, this is perfect, but remember that all engineering is knowing your constraints and getting the best for what you have.