DEV Community: Shane Dowling

Learning Python as a Platform Engineer — First Steps

Shane Dowling — Fri, 01 Jan 2021 14:48:49 +0000

Learning Python as a Platform Engineer — First Steps

I’ve relatively recently moved into a Platform Engineering position after working in very developer oriented teams for many years. What’s interesting is that the engineers you work with have much more diverse and interesting backgrounds in terms of their experience, so there’s a real opportunity to grow and learn a lot more, as opposed to a more homogenous set of developers. With that in mind, I wanted to put together materials on how a more ops focused engineer can up-skill in Python(as that’s more my wheel-house), in particular what are the things that would help you move into a more Python-focused role.

Where to start

Beginners who have no experience of Python are going to need to get their head around the fundamentals. I wouldn’t avoid reading books, but you’re going to get more impact delivering. Prioritise writing and reading code over anything else. One thing I’d always suggest is to try automate parts of your life with code. There’s a great book called “Automate the boring stuff with Python” if you need inspiration to focus on delivering.

Personally, when I needed a refresher in Python after several years of NodeJS, I started writing scripts that helped me to refresh myself. I wrote a script to alert me of the most up to date bus arrival times from TFL just before I’d usually leave the house in the morning, so I knew what time I had to leave.

On an ongoing basis, I maintain a simple Python project on an ongoing-basis that will watch a YouTube channel and automatically download any streams that appear. I use this project to test out things is like to try out, such as new libraries or programming concepts. It’s a safe way to try things out before I might suggest using it at work.

So to start with, pick a project.

What to avoid

Don’t read books and not output anything! It’s a trap of feeling productive while avoiding cementing any learnings. Think of it this way, you don’t want to “learn to code”, what you are is lazy and what you really want is to solve boring problems with code. You’re learning to use a hammer, find nails in your life to start banging away at!

Also avoid getting bogged down in setup. As an ops engineer, you might lean more into what you’re comfortable with. Just get something super basic working and don’t waste too much time on setup or use repl.it and forget about it! Heck I even wrote a post on coding on my iPad.

Set a goal

Don’t set a vague goal when learning to program, getting “better” doesn’t mean anything. Programming is about delivering projects and learning what works and what doesn’t. Focus on delivering small projects that help you in any small way and iterate on complexity. Don’t be afraid to set clear goals for yourself and share them with others.

If it helps try to think about it as a maturity vs capabilities. You don’t “mature” to be a developer, what would that even mean? Think of it more as adding capabilities to yourself, “I’m capable of writing a Python script, I’m capable of writing some tests, I’m capable of using boto to interact with AWS automatically”. Avoid thinking “I’ll read a bunch of books and be a developer some day”.

So set a goal of delivering a specific project at a specific date.

Figure it out

Now it’s time to start figuring out how to solve this problem you’ve set for yourself. At this stage I would say, look for what works best for you. Could you learn the basics more from say a book, a series of articles, a Udemy course? I’ve put some resources at the bottom of this post but this step really only you can define.

The one thing I would recommend is getting good at reading documentation, try to read up using the Python docs first before using Google/SO, but it’s fine if that’s what you need to do.

Asking for help

If you get stuck, ask for help. Ask colleagues, if you can’t ask them, ask on Stackoverflow or find a Python discord or IRC channel for example: https://pythondiscord.com/ and reach out. I can only speak for myself, but I always love helping people genuinely trying to learn but just getting blocked. If you can’t find any help at those resources and have some cash to spare, you can always use a service like https://codementor.io to get the expertise you need.

Automate your (platform) life

From a more platform-focused perspective, if you have say, manual things you do in AWS repeatedly, could that be turned into a quick script? Take a look at boto3 and see if there’s anything that could save you some time every day.

Some inspiration:

When an incident occurs in the systems you maintain, are there several things you might check depending on the type of incident that occurs? Perhaps you could automate pulling out some key data on your local machine to save some critical time.
Rotating keys, setting up users, any other admin tasks you could use avoid logging into your cloud platform?
Are there parts of your job where the UI of your cloud-provider of choice is a total pain(*cough* Cloudwatch… *cough*)? Perhaps you could avoid it by programming a solution.

Resources

In terms of resources you can use:

https://automatetheboringstuff.com — Great for inspiration to start projects.
https://www.twilio.com/quest/learn/python — If you can’t think of any projects you’d like to start, this looks like a fun way to crank out some lines of code.
https://www.fullstackpython.com/ — Deep dive into programming in Python.
https://www.youtube.com/watch?v=mvK0UzFNw1Q — Great video on where to start and explains why you should focus on delivering projects instead.
https://repl.it/ — Don’t get bogged down setting your local environment.
https://codementor.io/ — Pay to get expert help.

This is definitely enough to get a platform engineer started, I’ll expand on this series with next steps, so keep an eye! I’ll also start documenting how I’m growing from a Developer into a role demanding more Ops capabilities when I feel more comfortable myself.

Populate Ansible from Amazon secrets manager

Shane Dowling — Thu, 03 Sep 2020 18:06:58 +0000

Populate Ansible from AWS Secrets Manager

One of the ways to improve your security and avoid passing around env files is to follow the twelve factor app and start populating your secrets from the environment. Another improvement is to pull those secrets from a known secret store, with features like rotation, auditing etc.

Requirements

Ansible
Have some secrets stored in AWS Secrets Manager
Ansible should have access to the latest aws-cli command(secrets manager is a recent addition)
Jq if you’re storing json in your secrets

It’s worth testing your AWS calls to just extract the secret you’re interested in to stdout, from the terminal tests some calls like:

aws secretsmanager get-secret-value --secret-id some/secret/name --query SecretString --output text

Or for json you might do something like:

aws secretsmanager get-secret-value --secret-id secrets| jq --raw-output '.SecretString' | jq -r .API\_KEY

Ansible Config

Once you have secrets manager outputting your secrets to stdout, you can utilise it in Ansible. In this example I’m outputting to an env file but this could but used anywhere in Ansible. Instead of outputting to a file you could set its own environment variables then spin up the project from Ansible without outputting to a file anywhere.

- name: Setting env with some secret
  args:
    executable: /bin/bash
  shell: |
    aws secretsmanager get-secret-value --secret-id some/secret/name --query SecretString --output text
  register: some\_secret

- name: pass response of ssm to .env file
  become: no
  blockinfile:
    dest: '{{ some\_environment\_path }}/.env'
    state: present
    create: yes
    marker: "# {mark} MY SECRET FROM AWS #"
    block: |
      SOME\_SECRET='{{ some\_secret.stdout }}'

And that’s it! Anything I could’ve done better(which I’m sure there is), do let me know!

Better local development for Serverless Functions

Shane Dowling — Mon, 11 Feb 2019 20:15:38 +0000

Lambda is a terrific piece of kit for all the benefits listed on the AWS product page and Serverless is a very useful framework for developing Lambda functions. However, developing serverless applications locally is a total pain if what you’re solving isn’t totally trivial.

When things get complicated and your Lambda functions start to integrate with other AWS services, things really begin to break down. There are a few things that look like silver-bullets, I’ll share them here and explain why they didn’t work for me, then give you a working example that I myself struggled to find(hence me writing this).

Localstack

Localstack is definitely the biggest attempt at a silver bullet here. Basically it emulates a huge chunk of AWS locally and you connect your serverless functions into that. Why I didn’t use it:

Bits worked, but if you have any sort of half complicated setup(like a region outside us-east-1 or eu-west-1), it will break down. Uploading a whole cloudformation template was a disaster of broken links between services. I got to the point of editing localstack code to try fix issue after issue I was coming across and gave up. The product would be cool if it wasn’t trying to do something so super complicated.
It’s also a huge resource drain on a developer’s machine.
Fundamentally, you shouldn’t have to emulate half of AWS to test your code.

Serverless Offline

Serverless offline is fairly straightforward. It should allow you to spin up your functions locally and call them as needed. Where this fell down for me was that it required you to have HTTP endpoints for your lambda functions, all of our Lambda functions were driven either by SQS events or a Cron. We also instantiate our SNS topics in our code, so it would constantly attempt to create SNS topics and AWS would throw errors.

I also did try using serverless-offline-sqs but could not get it to drive events into our Lamdba functions.

I was burning a lot of time getting a dev environment setup and I realised that this was fundamentally the wrong approach. I needed to start writing proper unit tests and use mocking to emulate the infrastructure(I mean ideally they’d be isolated properly and infrastructure/functions would be totally ignorant of each other, but that’s for another day).

The Example

Say we’re developing an application that makes use of:

Lambda
MongoDB
SQS
SNS

Your lambda function connects to your MongoDB, does a thing and fires off occasional SNS notifications/SQS messages to other services.

Lambda

For the actual code being run, I was going to use jest to start writing tests. Jest works well and integrates nicely into serverless.

MongoDB

To emulate MongoDB, I’m going to use an in-memory version of MongoDB that ties nicely into our Mongoose models.

SQS/SNS

For any Amazon infrastructure, we’re going to use aws-sdk-mock. This is an excellent wrapper around sinon for mocking the AWS infrastructure, that’s super useful for unit tests as you’ll see later.

Tieing it all together

So firstly lets install our dependencies.

npm install aws-sdk-mock mongodb-memory-server sinon jest --save-dev

Let’s also create a tests folder to keep all this test code in.

mkdir tests

Setting up MongoDB

Now, for our code to integrate with our in-memory Mongo-DB server, we’re going to need to add a few setup/teardown functions and a Mongo Environment. Clone this repo and put:

setup.js
teardown.js
mongo-environment.js

into your new test folder.

In your root directory add a jest.config.js with this content.

module.exports = {
 globalSetup: './tests/setup.js',
 globalTeardown: './tests/teardown.js',
 testEnvironment: './tests/mongo-environment.js',
 roots: ['./tests/'],
};

This should be enough to get MongoDB up and running. Now onto our actual tests scripts.

Setting up our tests

Now, finally, you can tie it all together with this snippet:

Add jest to your package.json

"scripts":{ 
 "test": "jest"
},

And run with npm test .

One major point to note is that aws-mock-sdk requires a very specific way of instantiating AWS resources(within the scope of the function tests), so if you see any errors around aws regions, double check you’re following the rules.

Easy maintenance mode with nginx

Shane Dowling — Mon, 20 Aug 2018 18:51:42 +0000

So I combined a few solutions I found online to come up with a quick way to set up maintenance mode using nginx. Ideally it shouldn’t happen but in times of emergency in can be good to knock up a quick maintenance page for everyone but your own internal ips.

Nginx Config

So here’s the configuration I use for nginx, it starts with setting the internal ips of your company in the main nginx config file. Then in the actual vhost, you can set it to watch for the existence of a maintenance_on.html and when it exists, throw a 503 and use the maintenance page as your 503 error page.

How to use

By default I have the file named as maintenance_off.html, so it’s only a simple move operation to turn on maintenance mode. For the content of my maintenance file, I generally use this self-contained static html file to serve out a message to customers.

Note : Any sort of conditionals going on on your web server is likely to slow things down by a few milliseconds. Again you’re asking your web server to check against network and the disk per request, then make a decision, so bear this in mind before implementing a solution like this.