preevy VS configure-aws-credentials

Feel free to star the Preevy repo here.

We at Livecycle, a Docker-centric company, are super excited to share some highlights from the event and discuss how we are developing our products, Livecycle Docker Extension and Preevy, to improve collaboration, feedback, etc., in the vision that Docker is moving with their recent development and announcement at DockerCon.

To learn more about how to use Preevy, just check out the docs site.

Historically, many developers have preferred to facilitate this type of collaboration with ephemeral preview environments that are triggered with every PR or commit. And indeed, we have built robust solutions like “Preevy” to facilitate the creation of these environments for dockerized applications on any cloud or Kubernetes cluster.

Preevy also integrates into your CI pipeline to convert your pull requests into easily shareable ephemeral environments

My typical day is filled with a couple of meetings, building the Lifecycle community on Slack, collaborating with projects and people, and creating strategies and content (videos, blogs, short forms for Twitter and LinkedIn) around the product to increase adoption. I heavily focus on the company’s Open Source offering called Preevy which helps create a preview environment using Docker Compose underneath.

Also, at Livecycle, we are building Preevy, which helps you create a preview environment for Docker Compose applications. Do check out https://github.com/livecycle/preevy. It's open source, and don't forget to leave a star to show your support.

Check out the docs here

A dedicated docs site with relevant technical information and how-to guides for people who want to use it

About “Preevy” - an open source tool that simplifies the creation of preview environments

The AWS configure-aws-credentials Github Action allows the connection to the AWS S3 bucket through an AWS Role. The configuration of this role is explained in the next chapter

In this example, we'll be using the aws-actions/configure-aws-credentials action with GitHub's OIDC provider. Make sure the configured role has the required permissions.

The first step is to set up GitHub Actions as a recognized identity provider in my AWS account. This is also called an "OIDC Trust" relationship. In AWS IAM, create an Identity Provider with GitHub's provider URL and Audience. I am using the open-source action configure-aws-credentials (link) which means I want to use an Audience value of sts.amazonaws.com. Be sure to click the "Get Thumbprint" button to save a copy of the x.509 certificate used by GitHub into the AWS identity provider.

You can use configure-aws-credentials Github aciton. Which is pretty good. Here is a blog post about it from AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/

We are now ready to utilize configure-aws-credentials within our GitHub Actions as we move onto deploying our code!

The AssumeRoleWithWebIdentity error manifests itself mostly around parallel access attempts, and how the various AWS interfaces are able to authenticate, as well as run and deploy services. We started encountering this issue when running our pipelines for deployment, and attempting to authenticate our Github account to AWS via the OIDC plugin. This is a well-known (and widely discussed) limitation for authentication to AWS for web application providers. In our case it was Github, but this is true for pretty much any web application integration.

What you are looking at is totally doable, you MUST use: https://github.com/aws-actions/configure-aws-credentials

AWS Actions: It's an open source project from AWS which the goal is to get easy to Configure AWS credential and region environment variables for use in other GitHub Actions.

In order to achieve this, AWS credentials need to be properly configured. Here we use a handy Github action called configure-aws-credential, from AWS itself. You can also read more about the many methods of authentication available. This step requires the AWS_REGION and AWS_ROLE_ARN secrets to be properly configured in the repo, both of which that should be shared by the platform team.