Skip to content
This repository was archived by the owner on Dec 16, 2020. It is now read-only.

Commit dcf0f0c

Browse files
yorinasub17yorinasub17
committed
Boilerplate
1 parent 0d84128 commit dcf0f0c

File tree

4 files changed

+302
-0
lines changed

4 files changed

+302
-0
lines changed

‎.gitignore‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Terraform files
2+
.terraform
3+
terraform.tfstate
4+
terraform.tfvars
5+
*.tfstate*
6+
7+
# OS X files
8+
.history
9+
.DS_Store
10+
11+
# lambda zip files
12+
lambda.zip
13+
14+
# IntelliJ files
15+
.idea_modules
16+
*.iml
17+
*.iws
18+
*.ipr
19+
.idea/
20+
build/
21+
*/build/
22+
out/
23+
24+
# Go best practices dictate that libraries should not include the vendor directory
25+
vendor
26+
27+
# Python stuff
28+
dist
29+
aws_auth_configmap_generator.*
30+
.python-version
31+
.tox
32+
__pycache__
33+
*.pyc
34+
35+
# Folder used to store temporary test data by Terratest
36+
.test-data
37+
38+
# Generic temporary files
39+
/tmp

‎CONTRIBUTING.md‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# Contribution Guidelines
2+
3+
Contributions to this Package are very welcome! We follow a fairly standard [pull request process](
4+
https://help.github.com/articles/about-pull-requests/) for contributions, subject to the following guidelines:
5+
6+
1. [File a GitHub issue](#file-a-github-issue)
7+
1. [Update the documentation](#update-the-documentation)
8+
1. [Update the tests](#update-the-tests)
9+
1. [Update the code](#update-the-code)
10+
1. [Create a pull request](#create-a-pull-request)
11+
1. [Merge and release](#merge-and-release)
12+
13+
## File a GitHub issue
14+
15+
Before starting any work, we recommend filing a GitHub issue in this repo. This is your chance to ask questions and
16+
get feedback from the maintainers and the community before you sink a lot of time into writing (possibly the wrong)
17+
code. If there is anything you're unsure about, just ask!
18+
19+
## Update the documentation
20+
21+
We recommend updating the documentation *before* updating any code (see [Readme Driven
22+
Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the documentation
23+
stays up to date and allows you to think through the problem at a high level before you get lost in the weeds of
24+
coding.
25+
26+
## Update the tests
27+
28+
We also recommend updating the automated tests *before* updating any code (see [Test Driven
29+
Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test case,
30+
verify that it's failing with a clear error message, and *then* make the code changes to get that test to pass. This
31+
ensures the tests stay up to date and verify all the functionality in this Module, including whatever new
32+
functionality you're adding in your contribution. Check out the [tests](https://github.com/gruntwork-io/terraform-kubernetes-helm/tree/master/test) folder for instructions on running the
33+
automated tests.
34+
35+
## Update the code
36+
37+
At this point, make your code changes and use your new test case to verify that everything is working. As you work,
38+
keep in mind two things:
39+
40+
1. Backwards compatibility
41+
1. Downtime
42+
43+
### Backwards compatibility
44+
45+
Please make every effort to avoid unnecessary backwards incompatible changes. With Terraform code, this means:
46+
47+
1. Do not delete, rename, or change the type of input variables.
48+
1. If you add an input variable, it should have a `default`.
49+
1. Do not delete, rename, or change the type of output variables.
50+
1. Do not delete or rename a module in the `modules` folder.
51+
52+
If a backwards incompatible change cannot be avoided, please make sure to call that out when you submit a pull request,
53+
explaining why the change is absolutely necessary.
54+
55+
### Downtime
56+
57+
Bear in mind that the Terraform code in this Module is used by real companies to run real infrastructure in
58+
production, and certain types of changes could cause downtime. For example, consider the following:
59+
60+
1. If you rename a resource (e.g. `aws_instance "foo"` -> `aws_instance "bar"`), Terraform will see that as deleting
61+
the old resource and creating a new one.
62+
1. If you change certain attributes of a resource (e.g. the `name` of an `aws_elb`), the cloud provider (e.g. AWS) may
63+
treat that as an instruction to delete the old resource and a create a new one.
64+
65+
Deleting certain types of resources (e.g. virtual servers, load balancers) can cause downtime, so when making code
66+
changes, think carefully about how to avoid that. For example, can you avoid downtime by using
67+
[create_before_destroy](https://www.terraform.io/docs/configuration/resources.html#create_before_destroy)? Or via
68+
the `terraform state` command? If so, make sure to note this in our pull request. If downtime cannot be avoided,
69+
please make sure to call that out when you submit a pull request.
70+
71+
72+
### Formatting and pre-commit hooks
73+
74+
You must run `terraform fmt` on the code before committing. You can configure your computer to do this automatically
75+
using pre-commit hooks managed using [pre-commit](http://pre-commit.com/):
76+
77+
1. [Install pre-commit](http://pre-commit.com/#install). E.g.: `brew install pre-commit`.
78+
1. Install the hooks: `pre-commit install`.
79+
80+
That's it! Now just write your code, and every time you commit, `terraform fmt` will be run on the files you're
81+
committing.
82+
83+
84+
## Create a pull request
85+
86+
[Create a pull request](https://help.github.com/articles/creating-a-pull-request/) with your changes. Please make sure
87+
to include the following:
88+
89+
1. A description of the change, including a link to your GitHub issue.
90+
1. The output of your automated test run, preferably in a [GitHub Gist](https://gist.github.com/). We cannot run
91+
automated tests for pull requests automatically due to [security
92+
concerns](https://circleci.com/docs/fork-pr-builds/#security-implications), so we need you to manually provide this
93+
test output so we can verify that everything is working.
94+
1. Any notes on backwards incompatibility or downtime.
95+
96+
## Merge and release
97+
98+
The maintainers for this repo will review your code and provide feedback. If everything looks good, they will merge the
99+
code and release a new version, which you'll be able to find in the [releases page](../../releases).

‎GRUNTWORK_PHILOSOPHY.md‎

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
# Gruntwork Philosophy
2+
3+
At Gruntwork, we strive to accelerate the deployment of production grade infrastructure by prodiving a library of
4+
stable, reusable, and battle tested infrastructure as code organized into a series of [modules](#what-is-a-module) with
5+
[submodules](#what-is-a-submodule). Each module represents a particular set of infrastructure that is componentized into
6+
smaller pieces represented by the submodules within the module. By doing so, we have built a composable library that can
7+
be combined into building out everything from simple single service deployments to complicated microservice setups so
8+
that your infrastructure can grow with your business needs. Every module we provide is built with the [production grade
9+
infrastruture checklist](#production-grade-infrastructure-checklist) in mind, ensuring that the services you deploy are
10+
resilient, fault tolerant, and scalable.
11+
12+
13+
## What is a Module?
14+
15+
A Module is a reusable, tested, documented, configurable, best-practices definition of a single piece of Infrastructure
16+
(e.g., Docker cluster, VPC, Jenkins, Consul), written using a combination of [Terraform](https://www.terraform.io/), Go,
17+
and Bash. A module contains a set of automated tests, documentation, and examples that have been proven in production,
18+
providing the underlying infrastructure for [Gruntwork's customers](https://www.gruntwork.io/customers).
19+
20+
Instead of figuring out the details of how to run a piece of infrastructure from scratch, you can reuse existing code
21+
that has been proven in production. And instead of maintaining all that infrastructure code yourself, you can leverage
22+
the work of the community to pick up infrastructure improvements through a version number bump.
23+
24+
25+
## What is a Submodule?
26+
27+
Each Infrastructure Module consists of one or more orthogonal Submodules that handle some specific aspect of that
28+
Infrastructure Module's functionality. Breaking the code up into multiple submodules makes it easier to reuse and
29+
compose to handle many different use cases. Although Modules are designed to provide an end to end solution to manage
30+
the relevant infrastructure by combining the Submodules defined in the Module, Submodules can be used independently for
31+
specific functionality that you need in your infrastructure code.
32+
33+
34+
## Production Grade Infrastructure Checklist
35+
36+
At Gruntwork, we have learned over the years that it is not enough to just get the services up and running in a publicly
37+
accessible space to call your application "production-ready." There are many more things to consider, and oftentimes
38+
many of these considerations are missing in the deployment plan of applications. These topics come up as afterthoughts,
39+
and are learned the hard way after the fact. That is why we codified all of them into a checklist that can be used as a
40+
reference to help ensure that they are considered before your application goes to production, and conscious decisions
41+
are made to neglect particular components if needed, as opposed to accidentally omitting them from consideration.
42+
43+
<!--
44+
Edit the following table using https://www.tablesgenerator.com/markdown_tables. Start by pasting the table below in the
45+
menu item File > Paste table data.
46+
-->
47+
48+
| Task | Description | Example tools |
49+
|--------------------|-------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
50+
| Install | Install the software binaries and all dependencies. | Bash, Chef, Ansible, Puppet |
51+
| Configure | Configure the software at runtime. Includes port settings, TLS certs, service discovery, leaders, followers, replication, etc. | Bash, Chef, Ansible, Puppet |
52+
| Provision | Provision the infrastructure. Includes EC2 instances, load balancers, network topology, security gr oups, IAM permissions, etc. | Terraform, CloudFormation |
53+
| Deploy | Deploy the service on top of the infrastructure. Roll out updates with no downtime. Includes blue-green, rolling, and canary deployments. | Scripts, Orchestration tools (ECS, k8s, Nomad) |
54+
| High availability | Withstand outages of individual processes, EC2 instances, services, Availability Zones, and regions. | Multi AZ, multi-region, replication, ASGs, ELBs |
55+
| Scalability | Scale up and down in response to load. Scale horizontally (more servers) and/or vertically (bigger servers). | ASGs, replication, sharding, caching, divide and conquer |
56+
| Performance | Optimize CPU, memory, disk, network, GPU, and usage. Includes query tuning, benchmarking, load testing, and profiling. | Dynatrace, valgrind, VisualVM, ab, Jmeter |
57+
| Networking | Configure static and dynamic IPs, ports, service discovery, firewalls, DNS, SSH access, and VPN access. | EIPs, ENIs, VPCs, NACLs, SGs, Route 53, OpenVPN |
58+
| Security | Encryption in transit (TLS) and on disk, authentication, authorization, secrets management, server hardening. | ACM, EBS Volumes, Cognito, Vault, CIS |
59+
| Metrics | Availability metrics, business metrics, app metrics, server metrics, events, observability, tracing, and alerting. | CloudWatch, DataDog, New Relic, Honeycomb |
60+
| Logs | Rotate logs on disk. Aggregate log data to a central location. | CloudWatch logs, ELK, Sumo Logic, Papertrail |
61+
| Backup and Restore | Make backups of DBs, caches, and other data on a scheduled basis. Replicate to separate region/account. | RDS, ElastiCache, ec2-snapper, Lambda |
62+
| Cost optimization | Pick proper instance types, use spot and reserved instances, use auto scaling, and nuke unused resources. | ASGs, spot instances, reserved instances |
63+
| Documentation | Document your code, architecture, and practices. Create playbooks to respond to incidents. | READMEs, wikis, Slack |
64+
| Tests | Write automated tests for your infrastructure code. Run tests after every commit and nightly. | Terratest |

‎README.md‎

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
[![Maintained by Gruntwork.io](https://img.shields.io/badge/maintained%20by-gruntwork.io-%235849a6.svg)](https://gruntwork.io/?ref=repo_aws_eks)
2+
3+
# Helm Server Modules
4+
5+
This repo contains a Module for deploying Helm Server on Kubernetes clusters with [Terraform](https://www.terraform.io).
6+
This repo is a part of [the Gruntwork Infrastructure as Code
7+
Library](https://gruntwork.io/infrastructure-as-code-library/), a collection of reusable, battle-tested, production
8+
ready infrastructure code. Read the [Gruntwork Philosophy](GRUNTWORK_PHILOSOPHY.md) document to learn more about how
9+
Gruntwork builds production grade infrastructure code.
10+
11+
12+
## What is in this repo
13+
14+
This repo provides a Gruntwork IaC Package and has the following folder structure:
15+
16+
* [modules](/modules): This folder contains the main implementation code for this Module, broken down into multiple
17+
standalone Submodules.
18+
* [examples](/examples): This folder contains examples of how to use the Submodules. The [example root
19+
README](/examples/README.md) provides a quickstart guide on how to use the Submodules in this Module.
20+
* [test](/test): Automated tests for the Modules and examples.
21+
22+
The following submodules are available in this module:
23+
24+
- [k8s-namespace](/modules/k8s-namespace): Provision a Kubernetes `Namespace` with a default set of RBAC roles.
25+
- [k8s-service-account](/modules/k8s-service-account): Provision a Kubernetes `ServiceAccount`.
26+
- [k8s-helm-server](/modules/k8s-helm-server): Provision a namespaced secure Helm Server on an existing Kubernetes
27+
cluster.
28+
29+
## What is Kubernetes?
30+
31+
[Kubernetes](https://kubernetes.io) is an open source container management system for deploying, scaling, and managing
32+
containerized applications. Kubernetes is built by Google based on their internal proprietary container management
33+
systems (Borg and Omega). Kubernetes provides a cloud agnostic platform to deploy your containerized applications with
34+
built in support for common operational tasks such as replication, autoscaling, self-healing, and rolling deployments.
35+
36+
You can learn more about Kubernetes from [the official documentation](https://kubernetes.io/docs/tutorials/kubernetes-basics/).
37+
38+
39+
## What is Helm?
40+
41+
[Helm](https://helm.sh/) is a package and module manager for Kubernetes that allows you to define, install, and manage
42+
Kubernetes applications as reusable packages called Charts. Helm provides support for official charts in their
43+
repository that contains various applications such as Jenkins, MySQL, and Consul to name a few. Gruntwork uses Helm
44+
under the hood for the Kubernetes modules in this package.
45+
46+
Helm consists of two components: the Helm Client, and the Helm Server (Tiller)
47+
48+
### What is the Helm Client?
49+
50+
The Helm client is a command line utility that provides a way to interact with Tiller. It is the primary interface to
51+
installing and managing Charts as releases in the Helm ecosystem. In addition to providing operational interfaces (e.g
52+
install, upgrade, list, etc), the client also provides utilities to support local development of Charts in the form of a
53+
scaffolding command and repository management (e.g uploading a Chart).
54+
55+
### What is the Helm Server?
56+
57+
The Helm Server (Tiller) is a component of Helm that runs inside the Kubernetes cluster. Tiller is what
58+
provides the functionality to apply the Kubernetes resource descriptions to the Kubernetes cluster. When you install a
59+
release, the helm client essentially packages up the values and charts as a release, which is submitted to Tiller.
60+
Tiller will then generate Kubernetes YAML files from the packaged release, and then apply the generated Kubernetes YAML
61+
file from the charts on the cluster.
62+
63+
<!-- TODO: ## What parts of the Production Grade Infrastructure Checklist are covered by this Module? -->
64+
65+
66+
## Who maintains this Module?
67+
68+
This Module and its Submodules are maintained by [Gruntwork](http://www.gruntwork.io/). If you are looking for help or
69+
commercial support, send an email to
70+
[support@gruntwork.io](mailto:support@gruntwork.io?Subject=GKE%20Module).
71+
72+
Gruntwork can help with:
73+
74+
* Setup, customization, and support for this Module.
75+
* Modules and submodules for other types of infrastructure, such as VPCs, Docker clusters, databases, and continuous
76+
integration.
77+
* Modules and Submodules that meet compliance requirements, such as HIPAA.
78+
* Consulting & Training on AWS, Terraform, and DevOps.
79+
80+
81+
## How do I contribute to this Module?
82+
83+
Contributions are very welcome! Check out the [Contribution Guidelines](/CONTRIBUTING.md) for instructions.
84+
85+
86+
## How is this Module versioned?
87+
88+
This Module follows the principles of [Semantic Versioning](http://semver.org/). You can find each new release, along
89+
with the changelog, in the [Releases Page](../../releases).
90+
91+
During initial development, the major version will be 0 (e.g., `0.x.y`), which indicates the code does not yet have a
92+
stable API. Once we hit `1.0.0`, we will make every effort to maintain a backwards compatible API and use the MAJOR,
93+
MINOR, and PATCH versions on each release to indicate any incompatibilities.
94+
95+
96+
## License
97+
98+
Please see [LICENSE](/LICENSE) for how the code in this repo is licensed.
99+
100+
Copyright &copy; 2018 Gruntwork, Inc.

0 commit comments

Comments
 (0)