Define a table of blueprints to associate common functionality in tabular form.

Vertical alignment to classify the blueprint category, e.g.

• object storage
• containerisation
• networking
• orchestration
• serverless
• persistence

Horizontal alignment to classify the platform category, e.g.

• Application (e.g. NGINX vhost)
• Operating system (e.g. swap file)
• SaaS (S3, dynamodb, newrelic, etc.)
• PaaS (Cloudfoundry, heroku, etc.)
• IaaS (AWS, Azure, GCP, Openstack, Digitalocean, etc.)
• CaaS (Rancher stack, etc.)

role

In addition to the credentials required to access a cloud environment we can optionally specify additional roles to assume when provisioning blueprints.

The benefit of such fine-grained roles is that it provides additional security to ensure a blueprint can make changes outside the scope of the blueprint specification.

provisioning

Bedrock roles are just another form of blueprint,

Include blueprints:

• whistlepost-server - deploy ec2 instance with cloud-config user data
• whistlepost-bucket - S3 bucket for media storage
• whistlepost-table - dynamodb table for site content

IMAP server

Many of the challenges involved with provisioning Cloud infrastructure relate to the SOE build of organisations and limited Internet access.

Providing a Vagrant configuration that accounts for restricted Internet access can help to automate around these difficulties.

https://www.vagrantup.com/docs/vagrantfile/

Docker-based host for multiple whistlepost instances

Cli commands:

Role:

• add
• remove
• assume

Blueprint:

• init
• apply
• destroy

Manifest:

• init
• apply
• destroy

We can assume bedrock-blueprint-admin role for each execution so that environment variables don't require initialisation. This will be more secure.

Whilst terraform state can provide a record of individual blueprints, there is nothing that maintains a history of manifest execution and the constellations within.

• Dynamodb/s3 - record result of blueprint action, args, vars, execution result (success/error/indeterminate) and execution time alongside the constellation id.

• Lambda - provide an API to construct a summary of constellation state, using dynamodb table to list blueprints

• Lambda - API to destroy/unlock/force-copy individual blueprints

Add support for blue-green deployments by adding a dns mode configuration to service deployment.

When mode is set to "green" the fqdn would be prefixed with "green-" to allow multiple instances of the service to be deployed concurrently.

Once testing is complete the accelerator can be run again in "blue" mode which would update the fqdn to remove the green prefix.

Use spot instances for nginx, with multi-value route53 to manage routing.

• use lambda to update routing when spot instances added/removed

Provide container that can scale and load test arbitrary urls.

https://www.cisecurity.org/benchmark/docker/

https://github.com/docker/docker-bench-security

Creation of clusters, services.

• Ec2 asg, alb, Target groups
• Task definition
• Ssm parameter store

Similar to sdkman: https://sdkman.io/

e.g.

• curl -s https://basepatterns.org/aws/bastion | bash
• curl -s https://basepatterns.org/do/reverseproxy | bash

Blueprint for provisioned search engine.

Lambdas for data ingestion

Low code platforms provide a modern "drag and drop" approach to application building, however the same problems and concerns exist today as for similar approaches in the past.

One problem is how to maintain the application over time, that typically has underlying code that is difficult to maintain or not accessible at all.

Bedrock blueprints provide a foundation for building apps using best-practice architectures and design, that are secure, resilient and efficient. Predefined "constellations" provide example applications that are rapidly deployable to target Cloud environments.

A manifest provides a way to define one or more collections of blueprints (a constellation) and associated configurations that make up a complete architecture.

Often a single blueprint is not sufficient to define a Cloud architecture as they are more likely to be distributed across multiple services. For example, you might have an ECS cluster for web/API applications, RDS or DynamDB for persistence, and S3 for archiving.

Within each of these tiers are additional ancillary services such as route53 for well-known endpoints and/or service discovery, cloudwatch events/triggers, etc. The collection of blueprints that encapsulates and independent function is called a constellation. Multiple constellations may be defined in a single manifest such that an entire architecture may be provisioned.

A manifest also provides a higher-order language that can be used to unambiguously describe novel Cloud architectures that are composed of well-defined blueprints.

Implement haproxy acl restrictions to exclude admin paths: /system/*

https://openmaptiles.org

Generate reports from constellation state information.

• Architecture diagram - use the deployed blueprints to generate diagram of cloud services in use (use key with numbers to label diagram)
• Cost projection - use deployed blueprints to calculate cost of provisioned resources

Useful to provide restricted access to S3 content:

Steps are basically:

1. Create a cloudfront dist...

https://www.reddit.com/r/aws/comments/bxyun7/how_to_put_my_cognito_hosted_ui_in_front_of_my_s3/eqboy3i?utm_medium=android_app&utm_source=share

Use Google cloud run to deploy serverless containers:

https://cloud.google.com/run/

• Perpetual free tier for smaller workloads
• Docker as a managed service

Support uploading files to S3. Use cognito to determine identity and generate pre-signed url to upload file into user space of uploads bucket.

• Cognito user/identity pools
• S3 uploads bucket
• Lambda to generate pre-signed URLs

Provision a bedrock environment:

• Prerequisites: docker, cloud API access
• build/run developer env
• generate eyaml keys
• edit hiera using eyaml edit..
• run packer to generate image with puppet installed
• run terraform to provision environment

AWS:

• ECS cluster
• Tzurl service (fargate)
• Reverse proxy

Create a static site providing scripts to invoke bedrock blueprints.

Storage for static content

Create builds for:

• digital ocean puppet image
• AWS puppet Ami
• dream compute puppet image

https://blog.cryptoaustralia.org.au/2017/03/21/run-your-end-to-end-encrypted-chat-server-matrix-riot/

Support letsencrypt for cloudfront distributions:

https://github.com/dlapiduz/certbot-s3front

Similar tools:

• Terragrunt - wraps terraform scripts in custom format to reduce code duplication
• Astro - group terraform modules with dependencies and apply bulk operations

Ssh host with cron scheduled shutdown

Provide some examples configuration sets (constellations) to help getting started.

• AWS bastion (bastion-aws, bastion-roles)
• Vpc
• Nginx reverse proxy with S3 website

Provide info related to efficiency (cost), resilience (SLIs) and architecture.

Provision/update bedrock components automatically.

Sync component configuration to S3 bucket. Object update (add/remove) triggers codebuild for component type.

Squid + vpc routing.

• Lambda for maintaining url whitelist (domain/reason text)
• Spotfleet (one instance per AZ)

API host requires:

• ssh
• ufw

1. Support for different backends (S3, HTTP, etc.)

• e.g. s3 bucket: $(aws sts get-caller-identity | jq -r '.Account')-terraform-state

2. Support branching

• store state in separate path to allow for backup/restore
• by default copy state across branches to keep in sync and avoid conflicts: terraform init -force-copy -backend-config backend.tfvars

A web application to manage blueprint and constellation provisioning.

• Upload/remove manifest (S3 bucket)
• List/deploy manifests (constellation state from dynamodb)
• List constellations (blueprints/vars from dynamodb)
• Manifest preview (from terraform plan - codebuild)
• Destroy blueprint/constellation (codebuild)
• Cross-account provision

Create docker orchestration server:

https://www.nomadproject.io/intro/vs/kubernetes.html

blueprint

prerequisites

Before provisioning a new blueprint instance you should decide which provisioning model to use.

local

Local provisioning is supported by three backend types: local, S3 and remote.

A local backend has no prerequisites, but is also not recommended due to potential for data loss.

An S3 backend requires an AWS account configured via environment variables or local configuration file.

A remote backend for local execution requires terraform cloud file or environment-based configuration.

In addition local execution requires credentials for target environments, which may be the same credentials used for the backend.

In fact if you require provisioning to multiple different accounts it is advisable to use a remote execution model due to limitations of local execution with multiple credentials/accounts.

remote

Remote execution is supported by terraform cloud via standardised execution environments. Only the remote backend type is supported by this model.

A remote backend for remote execution only requires terraform cloud credentials configured via file or environment variables.

Note that there are limitations on remote execution of blueprints that contain local-exec provisioning, which also needs to be taken into consideration when deciding on the execution model.

provisioning

backend

Configure the blueprint backend using the backend command:

$ blueprint <id> backend <local|S3|remote> [options]

An S3 backend requires a bucket name for state.

A remote backend requires a terraform cloud organisation and a prefix for cloud workspaces.

workspace

You can use workspaces to manage multiple instances of the same blueprint. This is essential when using a remote backend as the local workspace is used to define the cloud workspaces.

$ blueprint <id> workspace new <name>

init

After configuration of the backend and workspace, initialisation of the blueprint instance will download required plugins and modules for execution.

$ blueprint <id> init

plan

A blueprint plan is used to identify required input variables and preview the changes made by provisioning. If you know the required input variables you may specify on the command line.

$ blueprint <id> plan [input vars]

apply

A blueprint instance is provisioned using the apply command. As with the plan command input variables may be specified to override defaults.

$ blueprint <id> apply [input vars]

multiple instances

By default a single blueprint instance is created with the"default" tag. You can create multiple instances of a blueprint by using the"tag" option supported by all blueprint commands.

$ blueprint --tag <tag> <id> <command>

Blueprint - a collection of scripts used to provision resources that provide a function or service. It should be self-contained in that no other blueprints are required for the resources to be provisioned

Constellation - one or more blueprints that combine to provide a complete solution. Blueprints may be combined in different ways depending on the requirements of the constellation

Manifest - one or more constellations that provide a complete solution architecture. Often a manifest may contain just one constellation, but does allow for architectural layering through multiple constellations.

Isolate state for different environments.

https://www.terraform.io/docs/state/workspaces.html

Support for configuring letsencrypt on various host configurations

Nginx- based host with papertrail, nginx- agent

https://www.savjee.be/2013/01/Using-AWStats-to-analyze-Amazon-S3-logs/

When container is waiting for input from stdin a ctrl+c exit doesn't stop the container