Using CodeArtifact with Poetry
In my last post I discussed how an artifact server is the best way to publish locally-developed Python packages. In this post, I show you how to set up the AWS CodeArtifact service and use it with pip and Poetry.
In my last post I discussed how an artifact server is the best way to publish locally-developed Python packages. In this post, I show you how to set up the AWS CodeArtifact service and use it with pip and Poetry.
Coming from a Java background, I consider the Python development process to be a bit of a mess. The pieces are all there: a central repository for publicly-available packages, a way to install the packages you want, and several ways to run your program with only those packages. But it seems that everybody has a different way to combine those pieces. So when a colleague introduced me to Poetry, my first reaction was “oh great, another tool that solves part of my problem.” But after spending time with it, I don’t want to build Lambdas any other way.
Different numbers of availability zones are appropriate for different workloads. This post helps you pick an appropriate number for your needs.
“Traditional” deployment patterns separate the application from its infrastructure. Lambda deployments turn this model on its head, binding the infrastructure tightly to the running code. This can be a challenge, especially when developing in a team: it is all too easy for one developer to accidentally overwrite another’s work. In this post I look at several deployment options, and how they impact a development team.
In my last post, I looked at how you could package your Lambda as a Docker image. In this post, I show how you can use the base Amazon images to build a “traditional” Lambda and ensure that it has libraries that are appropriate for the Lambda runtime environment.
Lambda Container Images were announced at re:Invent 2020, providing a new way to build and deploy Lambda functions. They arrived just in time to solve an annoying build problem for me, so got my attention. And there weren’t any tutorials floating around when I first Googled, so I figured it was worth writing one. But … Read More
I find the SAM (Serverless Application Model) CLI extremely frustrating to use on Linux, starting with installation. But this week I learned two things that simplify both installation and operation. I’m passing them on in the hopes that they’ll be useful to you as well.
Frequent database password changes are a best practice, because they reduce the “blast radius” if compromised. However, restarting your applications in order to pick up the latest password can be onerous in a large deployment. This post describes how to implement a custom Postgres datasource that calls on IAM to generate a password whenever your application opens a connection to the database.
Frequent database password changes are a best practice, because they reduce the “blast radius” if compromised. However, restarting your applications in order to pick up the latest password can be onerous in a large deployment. This post describes how to use AWSLabs database driver that retrieves the current password from Secrets Manager whenever your application opens a connection to the database.
AWS gives you two ways to store application configuration: Secrets Manager and Systems Manager Parameter Store. Both can store arbitrary configuration data. Both use IAM (Identity and Access Management) policies to control access. Both can encrypt the data. So which should you pick?