Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Humanitec AWS Reference Architecture implementation

License

NotificationsYou must be signed in to change notification settings

humanitec-architecture/reference-architecture-aws

Repository files navigation

⚠️ The present reference architecture implementation for AWS has been deprecated. It will continue to be available at this location for some time, but not receive further updates.

The deprecation only affects the reference implementation contained in this repository, not the underlying conceptual architectures and supplementary materials shown on theHumanitec website.

Humanitec AWS Reference Architecture

TL;DR

Skip the theory? Gohere to spin up your Humanitec AWS Reference Architecture Implementation.

Follow this learning path to master your Internal Developer Platform.

Building an Internal Developer Platform (IDP) can come with many challenges. To give you a head start, we’ve created a set ofreference architectures based on hundreds of real-world setups. These architectures described in code provide a starting point to build your own IDP within minutes, along with customization capabilities to ensure your platform meets the unique needs of your users (developers).

The initial version of this reference architecture has been presented by Mike Gatto, Sr. DevOps Engineer, McKinsey and Stephan Schneider, Digital Expert Associate Partner, McKinsey atPlartformCon 2023.

What is an Internal Developer Platform (IDP)?

AnInternal Developer Platform (IDP) is the sum of all the tech and tools that a platform engineering team binds together to pave golden paths for developers. IDPs lower cognitive load across the engineering organization and enable developer self-service, without abstracting away context from developers or making the underlying tech inaccessible. Well-designed IDPs follow a Platform as a Product approach, where a platform team builds, maintains, and continuously improves the IDP, following product management principles and best practices.

Understanding the different planes of the IDP reference architecture

When McKinsey originallypublished the reference architecture they proposed five planes that describe the different parts of a modern Internal Developer Platform (IDP).

AWS reference architecture Humanitec

Developer Control Plane

This plane is the primary configuration layer and interaction point for the platform users. It harbors the following components:

  • AVersion Control System. GitHub is a prominent example, but this can be any system that contains two types of repositories:
    • Application Source Code
    • Platform Source Code, e.g. using Terraform
  • Workload specifications. The reference architecture usesScore.
  • Aportal for developers to interact with. It can be the Humanitec Portal, but you might also useBackstage or any other portal on the market.

Integration and Delivery Plane

This plane is about building and storing the image, creating app and infra configs from the abstractions provided by the developers, and deploying the final state. It’s where the domains of developers and platform engineers meet.

This plane usually contains four different tools:

  • ACI pipeline. It can be Github Actions or any CI tooling on the market.
  • Theimage registry holding your container images. Again, this can be any registry on the market.
  • Anorchestrator which in our example, is the Humanitec Platform Orchestrator.
  • TheCD system, which can be the Platform Orchestrator’s deployment pipeline capabilities — an external system triggered by the Orchestrator using a webhook, or a setup in tandem with GitOps operators like ArgoCD.

Monitoring and Logging Plane

The integration of monitoring and logging systems varies greatly depending on the system. This plane however is not a focus of the reference architecture.

Security Plane

The security plane of the reference architecture is focused on the secrets management system. The secrets manager stores configuration information such as database passwords, API keys, or TLS certificates needed by an Application at runtime. It allows the Platform Orchestrator to reference the secrets and inject them into the Workloads dynamically. You can learn more about secrets management and integration with other secrets managementhere.

The reference architecture sample implementations use the secrets store attached to the Humanitec SaaS system.

Resource Plane

This plane is where the actual infrastructure exists including clusters, databases, storage, or DNS services. The configuration of the Resources is managed by the Platform Orchestrator which dynamically creates app and infrastructure configurations with every deployment and creates, updates, or deletes dependent Resources as required.

How to spin up your Humanitec AWS Reference Architecture

This repo contains an implementation of part of the Humanitec Reference Architecture for an Internal Developer Platform, including Backstage as optional Portal solution.

This repo covers the base layer of the implementation for AWS.

By default, the following will be provisioned:

  • VPC
  • EKS Cluster
  • IAM User to access the cluster
  • Ingress NGINX in the cluster
  • Resource Definitions in Humanitec for:
    • Kubernetes Cluster

Prerequisites

  • A Humanitec account with theAdministrator role in an Organization. Get afree trial if you are just starting.
  • An AWS account
  • AWS CLI installed locally
  • terraform installed locally
  • (Optional)Humanitec CLI installed locally
  • (Optional)GitHub CLI installed locally

Usage

Note: Using this Reference Architecture Implementation will incur costs for your AWS project.

It is recommended that you fully review the code before you run it to ensure you understand the impact of provisioning this infrastructure.Humanitec does not take responsibility for any costs incurred or damage caused when using the Reference Architecture Implementation.

This reference architecture implementation uses Terraform. You will need to do the following:

  1. Fork this GitHub repo, clone it to your local machine and navigate to the root of the repository.

  2. Set the required input variables. (seeRequired input variables)

  3. Ensure you are logged in withaws. (Follow thequickstart if you aren't)

    1. Login to Humanitec (your user needs to have theAdministrator role on the Humanitec Organization)

      humctl login
    2. Alternatively: Set theHUMANITEC_TOKEN environment variable to an appropriateHumanitec API token with theAdministrator role on the Humanitec Organization.

    For example:

    export HUMANITEC_TOKEN="my-humanitec-api-token"
  4. Run terraform:

    terraform initterraform planterraform apply

Required input variables

Terraform reads variables by default from a file calledterraform.tfvars. You can create your own file by renaming theterraform.tfvars.example file in the root of the repo and then filling in the missing values.

You can see find a details about each of those variables and additional supported variables underInputs.

Verify your result

Check for the existence of key elements of the reference architecture. This is a subset of all elements only. For a complete list of what was installed, review the Terraform code.

  1. Set theHUMANITEC_ORG environment variable to the ID of your Humanitec Organization (must be all lowercase):

    export HUMANITEC_ORG="my-humanitec-org"
  2. Verify the existence of the Resource Definition for the EKS cluster in your Humanitec Organization:

    curl -s https://api.humanitec.io/orgs/${HUMANITEC_ORG}/resources/defs/ref-arch \  --header"Authorization: Bearer${HUMANITEC_TOKEN}" \| jq .id,.type

    This should output:

    "ref-arch""k8s-cluster"
  3. Verify the existence of the newly created EKS cluster:

    aws eks list-clusters --region<your-region>

    This should output:

    {"clusters": ["ref-arch","[more previously existing clusters here]"    ]}

Enable a portal (optional)

Portal Prerequisites

Backstage requires a GitHub connection, which in turn needs:

  • A GitHub organization and permission to create new repositories in it. Go tohttps://github.com/account/organizations/new to create a new org (the "Free" option is fine). Note: is has to be an organization, a free account is not sufficient.

  • Configured GitHub access

    • Either using the GitHub CLI:

      gh auth login --scopes repo,workflow,admin:org,delete_repo
    • Or using a token:

      • Create a classic github personal access token withrepo,workflow,delete_repo andadmin:org scopehere.

      • Set theGITHUB_TOKEN environment variable to your token.

        export GITHUB_TOKEN="my-github-token"
  • Set theGITHUB_ORG_ID environment variable to your GitHub organization ID.

    export GITHUB_ORG_ID="my-github-org-id"
  • Install the GitHub App for Backstage into your GitHub organization

    • Rundocker run --rm -it -e GITHUB_ORG_ID -v $(pwd):/pwd -p 127.0.0.1:3000:3000 ghcr.io/humanitec-architecture/create-gh-app (image source) and follow the instructions:
      • “All repositories” ~> Install
      • “Okay, […] was installed on the […] account.” ~> You can close the window and server.

Portal Usage

  • Enablewith_backstage inside yourterraform.tfvars and configure the additional variables that a required for Backstage.
  • Perform anotherterraform apply

Verify portal setup

  • Fetch the DNS entry of the Humanitec Applicationbackstage, Environmentdevelopment.
  • Open the host in your browser.
  • Click the "Create" button and scaffold your first application.

Cleaning up

Once you are finished with the reference architecture, you can remove all provisioned infrastructure and the resource definitions created in Humanitec with the following:

  1. Delete all Humanitec Applications scaffolded using the Portal, if you used one, but not thebackstage app itself.

  2. Ensure you are (still) logged in withaws.

  3. Ensure you still have theHUMANITEC_TOKEN environment variable set to an appropriate Humanitec API token with theAdministrator role on the Humanitec Organization.

  4. Run terraform:

    terraform destroy

Terraform docs

Requirements

NameVersion
terraform>= 1.3.0
aws~> 5.17
github~> 5.38
helm~> 2.12
humanitec~> 1.0
kubernetes~> 2.25
random~> 3.5

Providers

NameVersion
humanitec~> 1.0

Modules

NameSourceVersion
base./modules/basen/a
github./modules/githubn/a
github_appgithub.com/humanitec-architecture/shared-terraform-modules//modules/github-appv2024-06-12
portal_backstage./modules/portal-backstagen/a

Resources

NameType
humanitec_service_user_token.deployerresource
humanitec_user.deployerresource

Inputs

NameDescriptionTypeDefaultRequired
aws_account_idAWS Account (ID) to usestringn/ayes
aws_regionAWS regionstringn/ayes
disk_sizeDisk size in GB to use for EKS nodesnumber20no
github_org_idGitHub org id (required for Backstage)stringnullno
humanitec_org_idHumanitec Organization ID (required for Backstage)stringnullno
instance_typesList of EC2 instances types to use for EKS nodeslist(string)
[
"t3.large"
]
no
with_backstageDeploy Backstageboolfalseno

Learn more

Expand your knowledge by heading over to our learning path, and discover how to:

  • Deploy the Humanitec reference architecture using a cloud provider of your choice
  • Deploy and manage Applications using the Humanitec Platform Orchestrator and Score
  • Provision additional Resources and connect to them
  • Achieve standardization by design
  • Deal with special scenarios

Master your Internal Developer Platform

About

Humanitec AWS Reference Architecture implementation

Topics

Resources

License

Stars

Watchers

Forks

Contributors8


[8]ページ先頭

©2009-2025 Movatter.jp