Commit 2378a250 authored by Matt Butcher's avatar Matt Butcher Committed by GitHub

Merge pull request #860 from technosophos/feat/nginx-example

docs(examples): add nginx example chart
parents 68e0032f e628b333
......@@ -2,3 +2,18 @@
This directory contains example charts to help you get started with
chart development.
## Alpine
The `alpine` chart is very simple, and is a good starting point.
It simply deploys a single pod running Alpine Linux.
## Nginx
The `nginx` chart shows how to compose several resources into one chart,
and it illustrates more complex template usage.
It deploys a `deployment` (which creates a `replica set`), a `config
map`, and a `service`. The replica set starts an nginx pod. The config
map stores the files that the nginx server can serve.
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
.git
name: nginx
description: A basic NGINX HTTP server
version: 0.1.0
keywords:
- http
- nginx
- www
- web
home: "https://github.com/kubernetes/helm"
sources:
- "https://hub.docker.com/_/nginx/"
maintainers:
- name: technosophos
email: mbutcher@deis.com
# nginx: An advanced example chart
This Helm chart provides examples of some of Helm's more powerful
features.
**This is not a production-grade chart. It is an example.**
The chart installs a simple nginx server according to the following
pattern:
- A `ConfigMap` is used to store the files the server will serve.
([templates/configmap.yaml](templates/configmap.yaml))
- A `Deployment` is used to create a Replica Set of nginx pods.
([templates/deployment.yaml](templates/deployment.yaml))
- A `Service` is used to create a gateway to the pods running in the
replica set ([templates/svc.yaml](templates/svc.yaml))
The [values.yaml](values.yaml) exposes a few of the configuration options in the
charts, though there are some that are not exposed there (like
`.image`).
The [templates/_helpers.tpl](templates/_helpers.tpl) file contains helper templates. The leading
underscore (`_`) on the filename is semantic. It tells the template renderer
that this file does not contain a manifest. That file declares some
templates that are used elsewhere in the chart.
Helpers (usually called "partials" in template languages) are an
advanced way for developers to structure their templates for optimal
reuse.
You can deploy this chart with `helm install docs/examples/nginx`. Or
you can see how this chart would render with `helm install --dry-run
--debug docs/examples/nginx`.
{{/* vim: set filetype=mustache: */}}
{{/*
Expand the name of the chart.
*/}}
{{define "name"}}{{default "nginx" .nameOverride | trunc 24 }}{{end}}
{{/*
Create a default fully qualified app name.
We truncate at 24 chars because some Kubernetes name fields are limited to this
(by the DNS naming spec).
*/}}
{{define "fullname"}}{{.Release.Name}}-{{default "nginx" .nameOverride | trunc 24 }}{{end}}
# This is a simple example of using a config map to create a single page
# static site.
apiVersion: v1
kind: ConfigMap
metadata:
name: {{template "fullname" .}}
labels:
release: {{.Release.Name}}
app: {{template "fullname" .}}
data:
# When the config map is mounted as a volume, these will be created as
# files.
index.html: {{default "Hello" .index | squote}}
test.txt: test
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
# This uses a "fullname" template (see _helpers)
# Basing names on .Release.Name means that the same chart can be installed
# multiple times into the same namespace.
name: {{template "fullname" .}}
labels:
# This is a convention. It makes it possible for an admin to query a cluster
# using Kubectl and find out what packages are managed by Helm. Helm itself
# does not depend on this label, though.
heritage: helm
# This makes it easy to search for all components of a release using kubectl.
release: {{.Release.Name}}
# This makes it easy to audit chart usage.
chart: {{.Chart.Name}}-{{.Chart.Version}}
spec:
replicas: {{default 1 .replicaCount}}
template:
metadata:
labels:
app: {{template "fullname" .}}
release: {{.Release.Name}}
spec:
containers:
- name: {{template "fullname" .}}
# Making image configurable is not necessary. Making imageTag configurable
# is a nice option for the user. Especially in the strange cases like
# nginx where the base distro is determined by the tag. Using :latest
# is frowned upon, using :stable isn't that great either.
image: "{{default "nginx" .image}}:{{default "stable-alpine" .imageTag}}"
imagePullPolicy: {{default "IfNotPresent" .pullPolicy}}
ports:
- containerPort: 80
# This (and the volumes section below) mount the config map as a volume.
volumeMounts:
- mountPath: /usr/share/nginx/html
name: wwwdata-volume
volumes:
- name: wwwdata-volume
configMap:
name: {{template "fullname" .}}
# This is a service gateway to the replica set created by the deployment.
# Take a look at the deployment.yaml for general notes about this chart.
apiVersion: v1
kind: Service
metadata:
name: {{template "fullname" .}}
labels:
heritage: helm
release: {{.Release.Name}}
chart: {{.Chart.Name}}-{{.Chart.Version}}
spec:
ports:
- port: {{default 80 .httpPort}}
targetPort: 80
protocol: TCP
name: http
selector:
app: {{template "fullname" .}}
# Default values for nginx.
# This is a YAML-formatted file.
# Declare name/value pairs to be passed into your templates.
# See the list at https://hub.docker.com/r/library/nginx/tags/
imageTag: "1.11.0"
# The port (defined on the service) to access the HTTP server.
httpPort: 8888
# Number of nginx instances to run
replicaCount: 1
index: >-
<h1>Hello</h1>
<p>This is a test</p>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment