DEV Community: Peter Nehrer

How to Remove an Unwanted Time Zone from MacOS Calendar

Peter Nehrer — Tue, 06 Aug 2024 15:09:54 +0000

In this entirely global world of software development, you likely find yourself working with people across multiple time zones. Keeping available time slots, meeting times, and working hour boundaries straight becomes a challenge when more time zones are added to your daily activities; adding or subtracting three hours between the East Coast and the West Coast becomes a habit, but anything more might give you a headache.

So you relent and start adding the requisite time zones to your MacOS Calendar, but...

*sigh*

You accidentally add the wrong one. Or, one blissfully departs from your daily life, and you certainly don't need the clutter in the Time Zone drop down.

No worries, just remove it, but... um, how??

The Calendar team, with all their legendary UX prowess, seem to have inconveniently omitted that capability!

After some googling around, all you find is some partially helpful advice on how to reset all Calendar settings by deleting this file:

~/Library/Preferences/com.apple.iCal.plist

Great, but do you have to lose all settings??

An Apple Support article advises deleting a specific property:

defaults delete com.apple.iCal 'RecentlyUsedTimeZones'

But maybe you can do one better -- just edit the list in the Xcode:

Open your Calendar and select a time zone that you want to keep (i.e., not one you will be removing). Quit the Calendar app.
In your Terminal, type:
open ~/Library/Preferences/com.apple.iCal.plist
This will open Xcode.
In Xcode, expand the property named RecentlyUsedTimeZones
Locate the time zone you wish to remove and replace it with the last time zone in the list
Remove the last time zone in the list by clicking the minus sign next to the item key

Tada! When you open your Calendar again, everything should be as you hoped.

And never think of this minor annoyance again! 😂

Create a Custom GitHub Action in Rust

Peter Nehrer — Mon, 29 Apr 2024 04:29:54 +0000

Anyone who gets into serious software development quickly realizes that the path to productivity leads through automation. This applies to both individuals as well as entire teams. When you automate repetitive development tasks, not only do you save time for your future self, but you also reduce human error, foster repeatability, and eliminate the bus factor.

Of course, there's a fine balance between automating too little and too much -- you probably don't want to spend way more time automating your tasks than it would actually take to perform them manually! This is where your tools and platforms come into play. While some tasks are "standard practices" that apply to every project of a certain type, and may be set up right at the start, high-value projects tend to evolve in unique ways that eventually require a great deal of customization.

What are GitHub Actions?

If you've used GitHub while working on a software project, chances are you've seen GitHub Actions being utilized for automating tasks such as enforcing code formatting, running unit tests, checking code quality, or even packaging and publishing the final software product.

As an integral part of the GitHub platform, GitHub Actions are tightly integrated into your software development life-cycle, right where your code lives, and where much of your daily product development and collaboration happens. They are quite intuitive and easy to grasp; they use domain language that you're likely familiar with, such as workflows, jobs, and steps. Your workflows are described in YAML files that are stored in Git along with the rest of your code. Best of all, they are free to use, and GitHub even provides free compute infrastructure to run your workflows!

In addition to a set of commonly required actions provided directly by the platform itself, GitHub supports a rich marketplace of third-party actions that seem to cover any engineering need under the sun. However, GitHub also allows you to create your own custom actions suitable for your project's specific needs. Of course, if you feel that your custom GitHub Action can be useful to others, you may even publish it to GitHub Marketplace!

There are a number of reasons you may find yourself in need of a custom GitHub Action. For instance, your software project workflow may require some specific tasks that aren't already available. You may also want to optimize your workflow, reducing the wait time or resources needed to perform the tasks. Or you may need to integrate with external systems that are internal to your team or company. Finally, you may want to develop and offer custom GitHub Actions for profit.

Custom GitHub Actions

While it's possible to build custom GitHub Actions in JavaScript, this approach imposes limits on what they can do. For example, they run directly on the runner and can only use binaries that are part of the runner image. The language itself may be a less-than-ideal choice for non-JavaScript developers.

You can also create composite actions, which consist of steps that use other actions, including shell scripts. However, if you prefer to write your action in any other language, GitHub allows you to supply the implementation as a Docker container image; when used in a job step, the runner will execute the action in its own Docker container.

For best results, you should place your custom action in its own GitHub repository. This will make it easier to share and evolve as its own project.

What defines a custom GitHub Action is a YAML descriptor file named action.yaml, which must reside in the root of the action's repository. It contains both required and optional pieces of data, such as the action's name, description, and how it runs -- essentially its type.

Docker-based actions require a Dockerfile to build the action's executable and package it into an image. In your action's descriptor, you can supply the path to your Dockerfile or the full Docker image URI. As you get started with developing your action, it may be convenient to specify the path to the Dockerfile; however, when you actually use your action in production, you'll benefit from building the image ahead of time and publishing it to a Docker registry (e.g., GitHub's own Container Registry).

There are several mechanisms that your Docker-based action can use to interact with the platform. For instance, the platform will set up your container with environment variables that point to shared files for your action's output parameters, job summary, and even environment variables to set up for subsequent steps.

Custom GitHub Actions may utilize input parameters that the user can provide when calling the action in a job step. These parameters are passed to your container as command-line arguments. This is the easiest way to parameterize your action. Your action's descriptor file must define any input parameters that you wish to support, including their name, type, default value, and whether they're required.

Custom GitHub Actions in Rust

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Rust has a rich ecosystem of frameworks and libraries that let you read, parse, and manipulate text files, interact with cloud services and databases, and perform any other job that your project's development workflow may require. And because of its strong typing and tight memory management, you are much less likely to write programs that behave unexpectedly in production.

It is also quite easy to build a Rust program that links all of its dependencies into a single executable file. When you also optimize your release build for size, you end up with a small Docker container image that is quick to load and takes very little memory to do its job.

Tips for building custom GitHub Actions in Rust

As you get started, consider the following tips to help you along:

1. Use the `act` tool to test-run your action

To speed up your development cycle, install and use the act tool to test-run your action directly in your development environment. This tool lets you invoke a GitHub workflow right on your local machine and will save you the round-trips of pushing each change to GitHub to see if it works.

2. Use debug messages

GitHub supports a debug mode when executing workflows. This will cause any debug message output to show up in the action's logs. This feature gives your users the ability to debug their workflows in a uniform manner.

3. Make your code easily testable

Write lots of unit tests, and use libraries that help you test filesystem operations, such as assert_fs, as well as your command-line parsing, such as assert_cmd. This will save you a lot of headaches with regression bugs as you build out your action's functionality.

4. Keep command-line argument parsing simple

Fancy command-line argument parsing simply isn't necessary when building a custom GitHub Action. All input parameters are described and fed statically into your executable's command-line arguments. That means that all parameters will always be supplied in the order you define in action.yaml, regardless of their values, so ensure that your code knows how to handle empty strings and defaults.

5. Use GitHub Actions to automate your own development process

Not surprisingly, you can invoke your own action as part of your action's automated workflow! In addition to your regular Rust-based project workflow, add one that calls your action with a set of resources that you can use to test its functionality.

6. Build and publish your Docker image to ghcr.io for free

Take full advantage of what GitHub has to offer, for free:

Build and package your action as a Docker container image as part of your release workflow.
Publish it to GitHub's Container Registry, which you can set up for your action's repository.
Update your action's descriptor to use the desired version of your pre-built Docker image, which will greatly speed up its execution!

7. Use Alpine-based Rust builder for statically-linked executables

For the smallest possible Docker container images, build your action using an Alpine Linux-based Rust builder. This image configures your Rust toolchain for static linking using the musl library, which produces single-file executables without any dynamic library dependencies. With this approach, your final Docker container image can consist of your executable alone, with no other files needed!

Next steps

To learn more, sign up for this interactive project on how to Build Custom GitHub Actions in Rust at Educative.io, which will take you step by step through creating your own custom GitHub Action in Rust!

The Undistributed System

Peter Nehrer — Wed, 27 Mar 2024 03:00:19 +0000

One common yet surprisingly stubborn problem in many evolving software products is the naive assumption that things happen in sequence. This situation is often the result of a noble intent -- don't over-architect, over-engineer the solution to something that seems like a simple problem at the outset. This simplification is often intentional, instituted in order to make the problem more manageable. After all, most systems aren't complex right from the start!

When a system is initially designed without considering the complexities of distributed computing, it often assumes a single, centralized state management approach. This design assumes consistent, instantaneous access to data, neglects the latency in communication between different parts of the system, and overlooks the possibility of node failures. Such assumptions are viable in a monolithic setup but become problematic when transitioning to a distributed architecture.

This conundrum isn't specific to globally distributed databases; it can occur in your single-zone Kubernetes cluster, or even a single-die, multi-core processor!

Time-based causality relies on the assumption that events can be ordered based on timestamps, ostensibly providing a straightforward way to determine the sequence of events in a distributed system. However, this approach is fraught with challenges.

The Challenges

For one, achieving data consistency across distributed nodes is a significant challenge. In a naive system, consistency is often taken for granted, assuming immediate visibility of all changes. However, in a distributed setting, data may be replicated across nodes, leading to potential inconsistencies due to network delays or partitions. Retrofitting consistency mechanisms like distributed consensus protocols can be complex and requires fundamental changes to how data is accessed and updated.

A non-distributed system may not have robust mechanisms for handling partial failures, as the entire system typically runs in a single process or machine. Distributed systems, by contrast, must be designed to tolerate failures of individual components without compromising the overall system availability. Implementing fault tolerance mechanisms, such as leader election, replication, and data recovery protocols, into a system not originally designed for this can be exceedingly challenging.

A naive system design often overlooks the impact of network latency and the possibility of network partitions. In distributed systems, these factors can significantly affect performance and consistency. Designing for distributed state use-cases requires careful consideration of these network issues, including strategies for dealing with partitioned networks and ensuring that the system can still function under such conditions.

Potential Mitigations

Conflict-Free Replicated Data Types (CRDTs) are data structures designed to ensure eventual consistency across distributed systems without the need for centralized coordination. They allow concurrent updates and resolve conflicts in a deterministic manner, ensuring convergence. However, CRDTs come with their trade-offs, including increased complexity in understanding and implementing these data structures, as well as the overhead of resolving conflicts, which can impact performance.

Distributed Consensus Protocols, such as Paxos or Raft, facilitate agreement among distributed processes on a single data value, ensuring consistency and fault tolerance. However, they incur costs in terms of latency due to the need for multiple rounds of communication between nodes to achieve consensus, and they also require a majority of nodes to be operational, limiting scalability in large, highly distributed environments.

Navigating the Trade-Offs

While CRDTs offer a way to sidestep the issues of time-based causality by enabling eventual consistency and conflict resolution without central coordination, they may not be suitable for applications requiring immediate consistency across all nodes. Distributed consensus protocols, on the other hand, provide strong consistency guarantees but at the expense of increased communication overhead and potential bottlenecks in decision-making processes.

TLDR;

Transitioning from a naive to a distributed system design is not merely an extension but a paradigm shift. It requires rethinking and often redesigning core components to handle the realities of distributed computing. Early consideration of distributed systems principles can mitigate these challenges, allowing for more seamless scaling and adaptation as requirements evolve. The process of retrofitting a system for distributed use-cases serves as a potent reminder of the complexity of distributed systems and the importance of incorporating distributed systems thinking from the outset of system design.

Configuring Rust Applications

Peter Nehrer — Mon, 25 Mar 2024 04:08:52 +0000

When building an application in any programming language, managing configuration is a fundamental aspect that determines how flexible and user-friendly your software can be. Among numerous crates available for handling configuration in Rust, two noteworthy options stand out: clap and figment. Both serve the purpose of managing application settings, but they cater to slightly different needs and use cases.

If you're happy (and you know it)

Clap is a powerful solution for parsing command-line arguments in Rust. It is designed to make the process of defining and accessing command-line parameters straightforward, with a focus on ease of use, customization, and comprehensive error handling. Clap allows developers to quickly add command-line parsing to their applications, supporting a wide range of scenarios from simple flag checks to more complex hierarchical subcommands.

Clap has a macro system that supports defining command-line options declaratively, which can significantly reduce boilerplate code. The crate automatically generates help messages based on the defined command-line arguments, ensuring that users always have access to guidance on how to use the application. Thanks to its robust error handling, clap provides detailed error messages when users input invalid arguments, making it easier for them to correct their mistakes.

The primary use-case for clap is a command-line tool that performs file operations based on user inputs, where users can specify file paths, operation modes, and other options directly through the CLI.

Not just your imagination

On the other hand, figment is a configuration library that is particularly suited for applications deployed in containerized environments, such as Docker. It focuses on sourcing configuration from a variety of formats and locations, such as environment variables, JSON, TOML files, and more. This flexibility makes figment an excellent choice for applications that need to adapt to different deployment environments without requiring code changes.

With its flexible configuration source providers, figment can pull configuration data from multiple sources, including files, environment variables, and even custom providers, allowing for a versatile setup that can adapt to various deployment scenarios. The crate also supports layered configuration, where settings can be overridden or merged from different sources. This is particularly useful in Docker-based applications, where environment-specific configurations might need to override defaults. Finally, figment supports deserializing configuration into strongly typed Rust structs, providing compile-time checks and reducing runtime errors.

Figment is best suited for web services deployed in Docker containers, where database URLs, API keys, and other sensitive settings need to be securely managed and easily changed between development, staging, and production environments without altering the codebase.

Apples, and orange apples

The primary difference between clap and figment lies in their focus areas. While clap is specialized in parsing command-line arguments, making it ideal for CLI tools and applications that require interactive user input, figment is designed with flexible, multi-source configuration in mind, perfect for applications deployed across different environments, especially in containers.

Despite their differences, clap and figment share common ground in their ability to utilize environment variables as a source of configuration. This feature is particularly beneficial in modern application development, where the flexibility to configure apps dynamically via the environment is essential for adapting to various deployment contexts without changing the code.

Clap integrates environment variables into its command-line parsing ecosystem, allowing developers to specify that certain command-line options can be also set or overridden by environment variables. This is useful for scenarios where sensitive information, such as API keys or database passwords, should not be passed directly on the command line or for providing defaults that can be overridden in different deployment environments.

Figment, inherently designed to handle configuration from multiple sources, treats environment variables as a first-class citizen. It allows developers to seamlessly merge or override configurations specified in files or hardcoded into the application with those specified as environment variables. This approach is especially advantageous in containerized applications, where environment variables are a common mechanism for passing configuration into containers.

In summary

For command-line argument parsing with rich user interaction, clap offers a comprehensive toolkit. Meanwhile, for Rust applications requiring versatile configuration management across different environments, especially in Docker-based deployments, figment provides an elegant and powerful solution. Both crates are excellent in their domains, and understanding their strengths can help developers leverage the best of Rust's ecosystem for configuration management.

What's your crate's Minimum Supported Rust Version?

Peter Nehrer — Wed, 04 Jan 2023 04:30:01 +0000

You worked hard to build your Rust library. You followed best practices, took advantage of those expressive yet concise language constructs, pulled in rock-solid dependencies instead of reinventing the wheel...

Your library is useful; its API lean and to the point, generic where it makes sense. Even your unit test coverage is decent!

You're ready to publish it for the world to enjoy.

But what version of Rust does it really require?

Maybe you're one of those fearless explorers who live on nightly. Or maybe you use the latest stable but keep it up-to-date as soon as a new release comes out so you can take take advantage of those sweet-sweet goodies that just about every new version delivers!

Before Rust 1.56, you'd have to informally document the version that you thought was required; for example, the one that you used to build your crate, or retroactively determined by installing older versions of Rust. Your users would then have to follow this advice.

However, starting with version 1.56 Rust allows crate authors to specify their Minimum Supported Rust Version as rust-version in Cargo.toml.

Nice! Yet the original problem persists -- what version should you enter into that field?

If you go with the version that you're currently on, then it's possible you're unnecessarily forcing your users to that version or newer.

On the other hand, constraining yourself to an older version doesn't bring much joy (unless of course you have a specific audience in mind).

Ready to dive into shell and whip up a for-loop to install every possible Rust version to see which one breaks the build?

Before getting overcome by despair, have a look at cargo-msrv -- this little gem of a tool figures it all out for you!

First, install it like you would any other cargo subcommand; e.g.:

cargo install cargo-msrv

Then, let it determine which Rust version your crate actually requires based on your code as well as your dependencies:

cargo msrv

Et violà:

Determining the Minimum Supported Rust Version (MSRV) for toolchain aarch64-apple-darwin
Using check command cargo check
Check for toolchain '1.61.0-aarch64-apple-darwin' succeeded
Check for toolchain '1.58.1-aarch64-apple-darwin' succeeded
Check for toolchain '1.57.0-aarch64-apple-darwin' succeeded
Check for toolchain '1.56.1-aarch64-apple-darwin' succeeded
   Finished The MSRV is: 1.56.1   ██████████████████████████████████████████████████████████████████████████████████████████████████████████ 00:00:45

Not only that; it'll also tell you why an earlier version would break the build! That way, you can decide if this is something that you can change or work around in order to support an older Rust version, thus potentially reaching a wider audience.

Once you've set your Cargo.toml's rust-version to the recommended value, you can verify that it still holds as you continue developing your crate:

cargo msrv verify

The tool offers a lot more helpful features.

Kudos to the author and thanks to all those who contributed; I was delighted to have discovered this very useful tool!

A Story of Rusty Containers, Queues, and the Role of Assumed Identity

Peter Nehrer — Wed, 26 Aug 2020 00:43:07 +0000

How to access Amazon Web Services from Rust-based Kubernetes applications using Rusoto and IAM Roles for Service Accounts

I made acquaintance with Rusoto only recently, while building a Rust service that consumed messages from Amazon SQS. I was instantly impressed with this AWS SDK for Rust -- well designed, modular, thoroughly documented, and even more comprehensive than typical AWS SDKs for other languages.

In order to set up my application to use SQS, all I had to do was add rusoto_core and rusoto_sqs crates to my Cargo.toml and create an instance of SqsClient for my target region. Even better, I could set it up with the default region, which causes it to look for the configured region in the usual environment variables or profile configuration files:

use rusoto_core::Region;
use rusoto_sqs::SqsClient;

let client = SqsClient::new(Region::default());

For my containerized application this was ideal, since in Kubernetes it would get its static configuration through environment variables anyway, and I could easily supply them when running locally:

RUST_LOG=debug AWS_REGION=ca-central-1 QUEUE_URL=https://sqs.ca-central-1.amazonaws.com/1234567890/rusoto-sqs-k8s-demo cargo run

Supplying AWS credentials

Similar to how it determines the desired service region, the default Rusoto client uses a discovery algorithm to obtain its AWS credentials; it checks the environment variables, profile configuration files, and even the IAM instance profile if running on an EC2 instance.

If any of the supplied credentials are configured to expire periodically, this provider would even refresh them as needed!

As expected, running my code locally was a breeze, since the client used my default AWS profile credentials, which were granted access to the SQS queue that I had set up for testing. I tried sending a test message to my queue using AWS CLI:

aws sqs send-message --queue-url https://sqs.ca-central-1.amazonaws.com/1234567890/rusoto-sqs-k8s-demo --message-body 'Hello world!'

Success! As my application's debug log indicated, it was able to receive and process the message:

{"timestamp":"Aug 23 23:58:09.780","level":"DEBUG","target":"rusoto_sqs_k8s_demo","fields":{"message":"Message { attributes: None, body: Some(\"Hello world!\"), md5_of_body: Some(\"86fb269d190d2c85f6e0468ceca42a20\"), md5_of_message_attributes: None, message_attributes: None, message_id: Some(\"d1ec1019-6398-4c75-b320-4a1e653e63ef\"), receipt_handle: Some(\"AQEBDrxJ...fnjddGjP8J6zvFKtw==\") }","log.target":"rusoto_sqs_k8s_demo","log.module_path":"rusoto_sqs_k8s_demo","log.file":"src/main.rs","log.line":129}}

In order to demonstrate the approach outlined in this article, I created a small demonstration project that's available on GitHub. Most of the code snippets and log outputs in this article are taken from this project. Please note that it is very minimalistic, focusing on the subject at hand and glossing over other important aspects, such as error handling, testing, and deployment. It could even use a more efficient Docker build! Perhaps more on that in another article...

Detour: Kubernetizing your application

Applications running in Kubernetes differ from typical CLI-based programs in a number of ways. For instance, they have different configuration and logging needs. Furthermore, they must support readiness and liveness probes, and gracefully shut down in response to the TERM signal. Finally, they must run in a Docker container.

Logging

Granted, log entries like the one shown earlier aren't as human-readable as those generated by e.g., the pretty_env_logger crate; however, because they are JSON, they are easily consumable by various application monitoring tools.

For Kubernetes applications that use tokio to implement asynchronous servers I typically reach for the tracing and tracing-subscriber crates. This pair gives me the ability to use the log crate as I normally would -- for logging -- as well as async-aware tracing, should the need arise. As a bonus, it provides JSON-formatted log output.

use tracing_subscriber::{
    fmt::Subscriber as TracingSubscriber,
    EnvFilter as TracingEnvFilter,
};

...

TracingSubscriber::builder()
    .with_env_filter(TracingEnvFilter::from_default_env())
    .json()
    .init();

Configuration

For better user experience with a CLI-based application, I would normally utilize a crate such as gumdrop in order to support argument-based configuration. However, there is no need for that in Kubernetes as the application primarily receives its configuration through environment variables passed down to it through Docker, config maps mounted as files on filesystem volumes, or dynamically through an external service (e.g., Consul).

The config create does the trick here -- it supports these types of configuration sources while allowing me to read configuration values into a typed struct:

use config::{
    Config,
    Environment,
};

use std::net::SocketAddr;

#[derive(Debug, Deserialize)]
struct Settings {
    #[serde(default = "Settings::default_status_probe_addr")]
    status_probe_addr: SocketAddr,
    queue_url: String,
}

impl Settings {
    fn default_status_probe_addr() -> SocketAddr {
        "0.0.0.0:8080"
            .parse()
            .expect("default status probe address")
    }
}

...

let mut cfg = Config::new();
cfg.merge(Environment::new())?;

let settings: Settings = cfg.try_into()?;

Build info

For easier debugging, I like to have the application log its current version at startup. This can be easily accomplished with the help of the built crate, which projects various build-time data, such as the current git hash, into constants, which can in turn be used to create the version string:

fn version() -> String {
    format!(
        "{} {} ({}, {} build, {} [{}], {})",
        env!("CARGO_PKG_NAME"),
        env!("CARGO_PKG_VERSION"),
        built_info::GIT_VERSION.unwrap_or("unknown"),
        built_info::PROFILE,
        built_info::CFG_OS,
        built_info::CFG_TARGET_ARCH,
        built_info::BUILT_TIME_UTC,
    )
}

Readiness and liveness probes

Kubernetes must be able to determine the health of each container in order to replace it in case the application runs into some unexpected trouble. To do that, the container can be configured with a readiness (checked upon startup) and a liveness probe (checked periodically), which tells Kubernetes when the container is ready to receive traffic as well as alive and healthy, respectively.

For the demo application, I chose a simple TCP connection probe -- as long as the application accepts the controller's connection request on the specified port, the probe is deemed successful:

use tokio::net::TcpListener;

...

let mut status_listener = TcpListener::bind(&settings.status_probe_addr).await?;
let mut probes = status_listener.incoming();

...

while let Some(_) = probes.next().await {
    ...
}

Signals

It's a good practice to have your application handle POSIX signals, especially the TERM signal, which the container host sends to the application upon graceful shutdown. The application should use that opportunity to finish processing any outstanding requests and clean up any open resources:

use futures::stream::SelectAll;
use tokio::signal::unix::{
    signal,
    SignalKind,
};

...

let mut signals = SelectAll::new();
signals.push(signal(SignalKind::interrupt()).expect("failed to register the interrupt signal"));
signals.push(signal(SignalKind::quit()).expect("failed to register the quit signal"));
signals.push(signal(SignalKind::terminate()).expect("failed to register the terminate signal"));
// ignore SIGPIPE
let _sigpipe = signal(SignalKind::pipe()).expect("failed to register the pipe signal");

...

if let Some(_) = signals.next().await {
    // Clean up and exit
    ...
}

Docker build

In order to run in Kubernetes, the application must be packaged as a Docker image. One of the easiest way to accomplish this is to create a multi-stage Dockerfile using Rust MUSL Builder to build the application and Alpine Linux as the base of the target image.

Rust MUSL Builder comes pre-installed with the desired Rust toolchain. Furthermore, it produces statically-linked builds, which comes in handy when running the binaries in Alpine Linux.

After verifying the formatting, running clippy, unit tests, and finally the release build (with the desired maximum logging level), the target binary is copied into Alpine Linux:

RUN cargo fmt --all -- --check
RUN cargo clippy --all -- -D warnings
RUN cargo test --all

ARG debug

ENV BUILD_FEATURES=${debug:+"--features log-level-trace"}

RUN cargo build --release --no-default-features $BUILD_FEATURES

Lastly, for better process handling, I recommend installing tini and having it spawn the actual application process:

RUN apk --no-cache add tini
...
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/app/rusoto-sqs-k8s-demo"]

Finally, running the build takes a good while:

docker build -t ecliptical/rusoto-sqs-k8s-demo .
Sending build context to Docker daemon  140.3kB
Step 1/17 : FROM ekidd/rust-musl-builder:nightly-2020-08-15 AS build
 ---> c39cf12c752f
 ...
  ---> ea152bab848a
Successfully built ea152bab848a
Successfully tagged ecliptical/rusoto-sqs-k8s-demo:latest

Deploying into Kubernetes

After the resounding success of the application's trial run on my laptop, I was ready to press ahead and deploy it into Kubernetes!

Your organization's approach for deploying applications into Kubernetes will likely vary. For instance, one might use the Amazon Elastic Container Registry (ECR) to host the Docker images, and Helm to simplify the various deployment descriptors and the actual roll-out procedures. However, for demonstration purposes a GitHub Package Registry and plain Kubernetes deployment descriptors applied using kubectl will suffice.

Docker registry

To allow Kubernetes to deploy a Docker container, it must be able to download the specified image from a Docker registry. For the demo project, I set up a GitHub Package Registry at docker.pkg.github.com/ecliptical/rusoto-sqs-k8s-demo and pushed the tagged build into it:

docker tag ecliptical/rusoto-sqs-k8s-demo docker.pkg.github.com/ecliptical/rusoto-sqs-k8s-demo/rusoto-sqs-k8s-demo:v1
docker push docker.pkg.github.com/ecliptical/rusoto-sqs-k8s-demo/rusoto-sqs-k8s-demo:v1

Hopefully, your organization's CI/CD system takes care of running the build and pushing it to the Docker registry!

Deployment descriptor

In order to deploy the application into Kubernetes, kubectl needs a deployment.yaml file that describes the various aspects of the deployment, including the containers and their configuration. This is where you supply static values for the various environment variables either directly or as secrets. In practice, these are often managed by the SRE team or other authorized personnel:

...
containers:
- name: rusoto-sqs-k8s-demo
  image: "docker.pkg.github.com/ecliptical/rusoto-sqs-k8s-demo/rusoto-sqs-k8s-demo:v1"
  imagePullPolicy: IfNotPresent
...
  env:
  - name: "AWS_REGION"
    value: ca-central-1
  - name: "AWS_ACCESS_KEY_ID"
    valueFrom:
      secretKeyRef:
        name: rusoto-sqs-k8s-demo-secrets
        key: aws_access_key_id
  - name: "AWS_SECRET_ACCCESS_KEY"
    valueFrom:
      secretKeyRef:
        name: rusoto-sqs-k8s-demo-secrets
        key: aws_secret_access_key
  - name: "QUEUE_URL"
    valueFrom:
      secretKeyRef:
        name: rusoto-sqs-k8s-demo-secrets
        key: queue_url
  - name: "RUST_LOG"
    value: info
...
imagePullSecrets:
- name: regsecret
...

Secrets

For the above deployment descriptor to work, there must a be a special regsecret and a generic rusoto-sqs-k8s-demo-secrets secret set up in the target namespace. For the demo, you can create the former like so (after replacing your GitHub credentials):

AUTH=$(echo -n YOUR_GITHUB_USERNAME:YOUR_GITHUB_API_TOKEN | base64)
echo '{"auths":{"docker.pkg.github.com":{"auth":"'${AUTH}'"}}}' | kubectl create secret -n demo generic regsecret --type=kubernetes.io/dockerconfigjson --from-file=.dockerconfigjson=/dev/stdin

And the latter (partially):

kubectl -n demo create secret generic rusoto-sqs-k8s-demo-secrets --from-literal=queue_url=https://sqs.ca-central-1.amazonaws.com/1234567890/rusoto-sqs-k8s-demo

For the actual application I asked the Operations Team to kindly set up the registry secret and issue a new set of AWS credentials for my new-fangled application with relevant permissions for the SQS queue in question...

Not so fast!

It turns out that issuing static AWS credentials (that is, the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY pair) to Kubernetes applications isn't a great idea! The preferred way is to have the application assume a designated IAM role, which can then be granted various permissions as needed. In contrast to access-key based credentials, which are issued to a user, IAM roles may be scoped specifically to the set of permissions that the application needs, thus improving your system's security posture through the principle of least privilege.

For "classic" applications running in EC2, this can be done through IAM instance profiles.

But what about Kubernetes?

Fine-grained IAM Roles for Service Accounts

Luckily, Kubernetes applications can take advantage of fine-grained IAM roles for service accounts. This approach combines Kubernetes' Role-Based Access Control (RBAC) with Amazon's Identity and Access Management (IAM). The details of this mechanism are somewhat involved -- it takes advantage of the fact that Kubernetes can issue projected service account tokens for pods. Since these are valid OIDC JWTs, Amazon's Secure Token Service (STS) can use them for authentication thanks to its support for OIDC federation. Thus, a Kubernetes pod with a specific service account may be linked to an IAM role through STS. This ends up being relatively straightforward particularly in Amazon's Elastic Kubernetes Service (EKS), since its control plane takes care of automatically provisioning, injecting, and periodically updating the necessary environment variables and projected filesystem volume. However, the same web-hook based mechanism can be implemented in other environments.

The bottom line -- with a little bit of additional Kubernetes configuration, my application can get access to automatically managed, periodically refreshed AWS credentials.

Creating IAM role

Your organization's policies will likely determine how to go about provisioning an IAM role for your application. For this demo, you can just use the AWS CLI:

aws iam create-policy --policy-name RusotoSQSK8sDemoConsumer --policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": ["sqs:DeleteMessage", "sqs:GetQueueUrl", "sqs:ChangeMessageVisibility", "sqs:DeleteMessageBatch", "sqs:ReceiveMessage", "sqs:GetQueueAttributes", "sqs:ChangeMessageVisibilityBatch"], "Resource": ["arn:aws:sqs:*:1234567890:*"]}]}'

This creates a RusotoSQSK8sDemoConsumer role with enough permissions to receive and process messages in any SQS queue in the given account.

OIDC provider setup

Depending on your particular environment, the steps for setting up an Open ID Connect provider for your Kubernetes cluster will vary. If using EKS, you can create the provider and configure your cluster to use it in one step with the help of eksctl:

eksctl utils associate-iam-oidc-provider --cluster rusoto-sqs-demo --approve
[ℹ]  eksctl version 0.26.0
[ℹ]  using region ca-central-1
[ℹ]  will create IAM Open ID Connect provider for cluster "rusoto-sqs-demo" in "ca-central-1"
[✔]  created

Kubernetes service account

Next, you need a Kubernetes service account annotated with the ARN of the previously provisioned IAM role, which you can then assign to your application pods.

Here again, eksctl makes this process a one-step operation:

eksctl create iamserviceaccount \
                --name rusoto-sqs-consumer \
                --namespace demo \
                --cluster rusoto-sqs-demo \
                --attach-policy-arn arn:aws:iam::123456789:policy/RusotoSQSK8sDemoConsumer \
                --approve
[ℹ]  eksctl version 0.26.0
[ℹ]  using region ca-central-1
[ℹ]  1 task: { 2 sequential sub-tasks: { create IAM role for serviceaccount "demo/rusoto-sqs-consumer", create serviceaccount "demo/rusoto-sqs-consumer" } }
[ℹ]  building iamserviceaccount stack "eksctl-rusoto-sqs-demo-addon-iamserviceaccount-demo-rusoto-sqs-consumer"
[ℹ]  deploying stack "eksctl-rusoto-sqs-demo-addon-iamserviceaccount-demo-rusoto-sqs-consumer"
[✔]  created serviceaccount "demo/rusoto-sqs-consumer"

Deployment descriptor changes

Finally, you can incorporate the required changes into your pods' deployment descriptor:

...
containers:
- name: rusoto-sqs-k8s-demo
...
  env:
  - name: "AWS_REGION"
    value: ca-central-1
  - name: "QUEUE_URL"
    valueFrom:
      secretKeyRef:
        name: rusoto-sqs-k8s-demo-secrets
        key: queue_url
  - name: "RUST_LOG"
    value: info
...
serviceAccountName: rusoto-sqs-consumer
securityContext:
  fsGroup: 65534
...

Two sets of changes stand out:

You no longer need the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables -- they've been removed.
The serviceAccountName property has been added specifying the desired service account name, and a securityContext section with the fsGroup property -- this instructs Kubernetes to mount filesystem volumes with user nobody as their owner (id 65534 in Linux), thus allowing the unprivileged application process to read the automatically injected web token file.

All in all, when the pod is deployed, the EKS control plane will automatically inject two new environment variables and mount a new filesystem volume containing the periodically refreshed OIDC JWT:

containers:
- name: rusoto-sqs-k8s-demo
...
  env:
  - name: AWS_ROLE_ARN
    value: arn:aws:iam::1234567890:role/eksctl-rusoto-sqs-demo-addon-iamserviceaccou-Role1-1UNI8CG3YVFKN
  - name: AWS_WEB_IDENTITY_TOKEN_FILE
    value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
  volumeMounts:
  - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
...

Rusoto credentials, revisited

One outstanding issue remained -- how is the application going to find and use these injected credentials?

Rusoto is quite flexible -- the rusoto_credential crate allows me to implement my own credential providers, which could obtain and refresh my application's AWS credentials from an arbitrary external source. With this in mind I set out to investigate what it would take to read the injected AWS_WEB_IDENTITY_TOKEN_FILE and call STS's AssumeRoleWithWebIdentity to exchange the OIDC JWT for AWS role credentials. Whew!

Invariably, the trail of breadcrumbs lead me to the rusoto_sts crate, which exposes the Amazon STS API. As I said before, Rusoto is modular and doesn't force you to package code that you won't need. After perusing the documentation for a bit in order to devise my plan of attack, there -- sitting unassumingly at the end of the list of exported structs -- I found the WebIdentityProvider.

I couldn't believe my luck!

With a single method call I could simply instantiate a different kind of credentials provider that would read the injected environment variables and files and make the appropriate STS calls to authenticate my AWS API calls:

use rusoto_core::{
    region::Region,
    request::HttpClient,
};

use rusoto_credential::AutoRefreshingProvider;
use rusoto_sqs::SqsClient;
use rusoto_sts::WebIdentityProvider;

...

let sqs_http = HttpClient::new()?;
let cred_provider = AutoRefreshingProvider::new(WebIdentityProvider::from_k8s_env())?;
let client = SqsClient::new_with(sqs_http, aws_client, Region::default());

Onward into Kubernetes, this time for real

With all required changes finally in place, and the Docker image rebuilt and pushed into the registry, I was finally able to deploy the application. For the demo application, the equivalent procedure would simply be:

kubectl apply -f deployment.yaml
deployment.apps/rusoto-sqs-k8s-demo created

After receiving similarly positive yet rather anti-climactic output, I tailed the pods' logs to see if another test message sent to the target SQS queue would be picked up:

kubectl -n demo logs -f -l app.kubernetes.io/name=rusoto-sqs-k8s-demo
{"timestamp":"Aug 23 23:57:51.508","level":"INFO","target":"rusoto_sqs_k8s_demo","fields":{"message":"rusoto-sqs-k8s-demo 0.1.0 (4b04653, release build, linux [x86_64], Sun, 23 Aug 2020 19:12:11 +0000)","log.target":"rusoto_sqs_k8s_demo","log.module_path":"rusoto_sqs_k8s_demo","log.file":"src/main.rs","log.line":189}}
{"timestamp":"Aug 23 23:57:51.488","level":"INFO","target":"rusoto_sqs_k8s_demo","fields":{"message":"rusoto-sqs-k8s-demo 0.1.0 (4b04653, release build, linux [x86_64], Sun, 23 Aug 2020 19:12:11 +0000)","log.target":"rusoto_sqs_k8s_demo","log.module_path":"rusoto_sqs_k8s_demo","log.file":"src/main.rs","log.line":189}}
{"timestamp":"Aug 23 23:57:51.690","level":"INFO","target":"rusoto_sqs_k8s_demo","fields":{"message":"rusoto-sqs-k8s-demo 0.1.0 (4b04653, release build, linux [x86_64], Sun, 23 Aug 2020 19:12:11 +0000)","log.target":"rusoto_sqs_k8s_demo","log.module_path":"rusoto_sqs_k8s_demo","log.file":"src/main.rs","log.line":189}}

{"timestamp":"Aug 23 23:58:09.780","level":"INFO","target":"rusoto_sqs_k8s_demo","fields":{"message":"Message { attributes: None, body: Some(\"Hello world!\"), md5_of_body: Some(\"86fb269d190d2c85f6e0468ceca42a20\"), md5_of_message_attributes: None, message_attributes: None, message_id: Some(\"d1ec1109-6398-4c75-b032-4a1e6536e3ef\"), receipt_handle: Some(\"AQEBDwfG...fnjddGjP8J6zvFKtw==\") }","log.target":"rusoto_sqs_k8s_demo","log.module_path":"rusoto_sqs_k8s_demo","log.file":"src/main.rs","log.line":129}}

Sweet victory!

Have your token-based identity and eat it, too

Ultimately, I decided to support both injected and static AWS credentials in order to make it easier to run the app locally. If the injected credentials are available, then let's use those:

use rusoto_core::{
    region::Region,
    request::HttpClient,
    Client as AwsClient,
};

use rusoto_credential::AutoRefreshingProvider;
use rusoto_sqs::SqsClient;
use rusoto_sts::WebIdentityProvider;
use std::env::var_os;

...

let token_file = var_os("AWS_WEB_IDENTITY_TOKEN_FILE");
let role = var_os("AWS_ROLE_ARN");

let aws_client =
    if token_file.map_or(true, |v| v.is_empty()) || role.map_or(true, |v| v.is_empty()) {
        AwsClient::shared()
    } else {
        let sqs_http = HttpClient::new()?;
        let cred_provider = AutoRefreshingProvider::new(WebIdentityProvider::from_k8s_env())?;
        AwsClient::new_with(cred_provider, sqs_http)
    };

let client = SqsClient::new_with_client(aws_client, Region::default());

Conclusion

Even with Kubernetes at the helm, navigating the cloudy skies can become an arduous endeavor, especially when faced with complex, sensitive issues such as application security and controlling access to AWS resources.

Thankfully, Rusoto provides an easy way to tap into Amazon's support for IAM roles for Kubernetes service accounts, which bridge the Kubernetes and AWS worlds in terms of security and access control.

I am grateful for and continue to be amazed by all the generous contributions of the open-source Rust community, which make it possible for me and many others to build applications using this powerful, modern language platform.

To follow the examples in this article please see the accompanying project on GitHub.

Splash photo by Rinson Chory on Unsplash

A Curious Tale of Rust TLS and Postgres in the Cloud

Peter Nehrer — Mon, 03 Aug 2020 15:54:27 +0000

How to Connect Securely to Amazon RDS for PostgreSQL using Tokio and Rustls

Recently I ran into a curious problem while working on a piece of asynchronous database code for a micro-service written in Rust -- it looked something like this:



 DEBUG rustls::client::tls12          > Server DNS name is DNSName("database-1.xq7f5vzbpq1x.ca-central-1.rds.amazonaws.com")
 WARN  rustls::session                > Sending fatal alert BadCertificate
Error: Backend(Error { kind: Tls, cause: Some(Kind(InvalidInput)) })

This particular module used Tokio Postgres along with Deadpool Postgres -- part of my favorite Rust stack -- to interact with an AWS RDS for PostgreSQL database. Of course, everything worked great when I ran it against a Postgres instance deployed in my local Docker container -- the Deadpool documentation contains easy-to-follow examples that can get you going in minutes.

I knew I’d have to support connecting to the database securely in order to deploy the code to production -- the deployment policy requires (as it should!) that all connections to RDS instances use TLS. By default, the Tokio Postgres crate supports plain-text connections to help you get started, but luckily also outlines steps to enable TLS.

To be honest, I was a bit crestfallen when I didn’t see Rustls listed as one of the supported methods; only (effectively) OpenSSL. After all, there are many good reasons to use Rustls, in addition to the fact that it was already part of my stack (e.g., both Reqwest and Warp support it) and would allow me to crank out statically linked binaries more easily.

Never fear -- the amazing Rust community has your back! A quick search through crates.io produced the tokio-postgres-rustls crate, which was exactly what I needed; after a small addition to my configuration and database connection pool setup, I was on my way:



use config::{
    Config,
    Environment,
};

use deadpool_postgres::{
    Config as PoolConfig,
    Pool,
};

use rustls::ClientConfig as RustlsClientConfig;
use serde::Deserialize;
use tokio_postgres::NoTls;
use tokio_postgres_rustls::MakeRustlsConnect;

#[derive(Debug, Deserialize)]
struct Settings {
    pg: PoolConfig,
    #[serde(default)]
    use_tls: bool,
}

#[tokio::main]
async fn run(pool: Pool) -> Result<(), Box<dyn std::error::Error>> {
    let client = pool.get().await?;
    ...
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut config = Config::new();
    config.merge(Environment::new())?;

    let settings: Settings = config.try_into()?;

    let pool = if settings.use_tls {
        let tls_config = RustlsClientConfig::new();
        let tls = MakeRustlsConnect::new(tls_config);
        settings.pg.create_pool(tls)?
    } else {
        settings.pg.create_pool(NoTls)?
    };

    run(pool)
}

Reality Bites

As luck would have it, after pointing my Postgres client configuration to the RDS instance, I was met with the unpleasant surprise I had mentioned earlier -— BadCertificate error! Wha… wha… whad’ya MEAN??

I must admit -- in all my excitement I only skimmed through tokio-postgres-rustls documentation, and didn’t even peek at rustls, since the basic configuration example happened to compile just fine (yikes!). After a stern mental self-admonishment I carefully scanned Rustls’s Getting Started example and sure enough, I discovered that I may have missed a step:



    tls_config.root_store.add_server_trust_anchors(&webpki_roots::TLS_SERVER_ROOTS);

Of course! Rustls (probably) doesn’t come with any pre-configured root certificates! That would make sense -— Rust libraries tend to defer use-case-specific decisions to the user -- why include files/bytes that may not even be needed?

Take Two

Ok -- new dependency included, Mozilla’s trusted root certificates added. That must have been the problem! Alas, the same error:



 DEBUG rustls::client::tls12          > Server DNS name is DNSName("database-1.xq7f5vzbpq1x.ca-central-1.rds.amazonaws.com")
 WARN  rustls::session                > Sending fatal alert BadCertificate
Error: Backend(Error { kind: Tls, cause: Some(Kind(InvalidInput)) })

“This means war!”, I thought to myself. Rather, it meant that I had to read the documentation more carefully -— a little bit of sleuthing revealed that AWS utilized their own/separate root certificates for their RDS instances. This, it turns out, is also helpfully indicated in the database instance details in RDS console -— if you know what to look for!

Third Time’s a Charm

After downloading the requisite root certificate and adding it to my database pool’s TLS configuration:



use config::{
    Config,
    Environment,
};

use deadpool_postgres::{
    Config as PoolConfig,
    Pool,
};

use rustls::ClientConfig as RustlsClientConfig;
use serde::Deserialize;
use std::{
    fs::File,
    io::BufReader,
};

use tokio_postgres::NoTls;
use tokio_postgres_rustls::MakeRustlsConnect;

#[derive(Debug, Deserialize)]
struct Settings {
    pg: PoolConfig,
    db_ca_cert: Option<String>,
}

#[tokio::main]
async fn run(pool: Pool) -> Result<(), Box<dyn std::error::Error>> {
    let client = pool.get().await?;
    ...
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut config = Config::new();
    config.merge(Environment::new())?;

    let settings: Settings = config.try_into()?;

    let pool = if let Some(ca_cert) = settings.db_ca_cert {
        let mut tls_config = RustlsClientConfig::new();
        let cert_file = File::open(&ca_cert)?;
        let mut buf = BufReader::new(cert_file);
        tls_config.root_store.add_pem_file(&mut buf).map_err(|_| {
            anyhow::anyhow!("failed to read database root certificate: {}", ca_cert)
        })?;

        let tls = MakeRustlsConnect::new(tls_config);
        settings.pg.create_pool(tls)?
    } else {
        settings.pg.create_pool(NoTls)?
    };

    run(pool)
}

Success!



DEBUG rustls::anchors                > add_pem_file processed 1 valid and 0 invalid certs

 DEBUG rustls::client::hs             > No cached session for DNSNameRef("database-1.xq7f5vzbpq1x.ca-central-1.rds.amazonaws.com")

 DEBUG rustls::client::hs             > Not resuming any session

 DEBUG rustls::client::hs             > ALPN protocol is None

 DEBUG rustls::client::hs             > Using ciphersuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

 DEBUG rustls::client::tls12          > ECDHE curve is ECParameters { curve_type: NamedCurve, named_group: secp256r1 }

 DEBUG rustls::client::tls12          > Got CertificateRequest CertificateRequestPayload { certtypes: [RSASign, DSSSign, ECDSASign], sigschemes: [RSA_PKCS1_SHA512, Unknown(1538), ECDSA_NISTP521_SHA512, RSA_PKCS1_SHA384, Unknown(1282), ECDSA_NISTP384_SHA384, RSA_PKCS1_SHA256, Unknown(1026), ECDSA_NISTP256_SHA256, Unknown(769), Unknown(770), Unknown(771), RSA_PKCS1_SHA1, Unknown(514), ECDSA_SHA1_Legacy], canames: [PayloadU16([48, 129, 151, 49, 11, 48, 9, 6, 3, 85, 4, 6, 19, 2, 85, 83, 49, 19, 48, 17, 6, 3, 85, 4, 8, 12, 10, 87, 97, 115, 104, 105, 110, 103, 116, 111, 110, 49, 16, 48, 14, 6, 3, 85, 4, 7, 12, 7, 83, 101, 97, 116, 116, 108, 101, 49, 34, 48, 32, 6, 3, 85, 4, 10, 12, 25, 65, 109, 97, 122, 111, 110, 32, 87, 101, 98, 32, 83, 101, 114, 118, 105, 99, 101, 115, 44, 32, 73, 110, 99, 46, 49, 19, 48, 17, 6, 3, 85, 4, 11, 12, 10, 65, 109, 97, 122, 111, 110, 32, 82, 68, 83, 49, 40, 48, 38, 6, 3, 85, 4, 3, 12, 31, 65, 109, 97, 122, 111, 110, 32, 82, 68, 83, 32, 99, 97, 45, 99, 101, 110, 116, 114, 97, 108, 45, 49, 32, 50, 48, 49, 57, 32, 67, 65])] }

 DEBUG rustls::client::tls12          > Client auth requested but no cert/sigscheme available

 DEBUG rustls::client::tls12          > Server cert is [Certificate(b"0\x82\x04\xe30\x82\x03\xcb\xa0\x03\x02\x01\x02\x02\x10\0\xc9\x0b^\x92\x04V\xa9\xd4#b*yh ;

 ...

 \xcc\xf5\xb8\tu\xef\x84\xb9\x84\xd3d\xc0\xf7\xf1\xde\x0b\r\xca\x10r0\x89\xc3n\x11\xfc")]

 DEBUG rustls::client::tls12          > Server DNS name is DNSName("database-1.xq7f5vzbpq1x.ca-central-1.rds.amazonaws.com")

 DEBUG rustls::client::tls12          > Session not saved: server didn't allocate id or ticket

 DEBUG tokio_postgres::prepare        > preparing query s0: SELECT * FROM information_schema.information_schema_catalog_name

 DEBUG tokio_postgres::query          > executing statement s0 with parameters: []

 INFO  tokio_postgres_rustls_rds_demo > postgres

Conclusion

There are many great libraries that help you build modern micro-services and native cloud applications in Rust. If you ever find yourself working with PostgreSQL, use Tokio Postgres with Deadpool to build responsive, scalable applications with Rust’s powerful asynchronous constructs.

To secure your client connection, use Rustls; however, make sure it is configured properly either with Mozilla’s trusted root certificates or your service provider’s own root certificates!

To try the approach outlined in this article, check out the demo project hosted on GitHub.

Splash photo by Paweł Czerwiński on Unsplash.

DEV Community: Peter Nehrer

How to Remove an Unwanted Time Zone from MacOS Calendar

Create a Custom GitHub Action in Rust

What are GitHub Actions?

Custom GitHub Actions

Custom GitHub Actions in Rust

Tips for building custom GitHub Actions in Rust

1. Use the act tool to test-run your action

2. Use debug messages

3. Make your code easily testable

4. Keep command-line argument parsing simple

5. Use GitHub Actions to automate your own development process

6. Build and publish your Docker image to ghcr.io for free

7. Use Alpine-based Rust builder for statically-linked executables

Next steps

The Undistributed System

The Challenges

Potential Mitigations

Navigating the Trade-Offs

TLDR;

Configuring Rust Applications

If you're happy (and you know it)

Not just your imagination

Apples, and orange apples

In summary

What's your crate's Minimum Supported Rust Version?

A Story of Rusty Containers, Queues, and the Role of Assumed Identity

How to access Amazon Web Services from Rust-based Kubernetes applications using Rusoto and IAM Roles for Service Accounts

Supplying AWS credentials

Detour: Kubernetizing your application

Logging

Configuration

Build info

Readiness and liveness probes

Signals

Docker build

Deploying into Kubernetes

Docker registry

Deployment descriptor

Secrets

Not so fast!

Fine-grained IAM Roles for Service Accounts

Creating IAM role

OIDC provider setup

Kubernetes service account

Deployment descriptor changes

Rusoto credentials, revisited

Onward into Kubernetes, this time for real

Have your token-based identity and eat it, too

Conclusion

A Curious Tale of Rust TLS and Postgres in the Cloud

How to Connect Securely to Amazon RDS for PostgreSQL using Tokio and Rustls

Reality Bites

Take Two

Third Time’s a Charm

Conclusion

1. Use the `act` tool to test-run your action