Add a CNAME and recent posts
This commit is contained in:
parent
45a5d70053
commit
b3c3478cd8
|
@ -1,6 +1,6 @@
|
||||||
---
|
---
|
||||||
layout: post
|
layout: post
|
||||||
title: Deciding who you are by why you eat.
|
title: Deciding who you are by what you eat.
|
||||||
tags:
|
tags:
|
||||||
- food
|
- food
|
||||||
- garden
|
- garden
|
||||||
|
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
layout: post
|
||||||
|
title: A most beautiful place
|
||||||
|
tags:
|
||||||
|
- sonoma
|
||||||
|
- santarosa
|
||||||
|
---
|
||||||
|
|
||||||
|
The wind carries the spring
|
||||||
|
<br/>
|
||||||
|
along the roadside
|
||||||
|
<br/>
|
||||||
|
down, over, and through the hills.
|
||||||
|
|
||||||
|
Winter's rain did come; too late to help.
|
||||||
|
<br/>
|
||||||
|
|
||||||
|
Lush green grasses, bright mustard flower
|
||||||
|
<br/>
|
||||||
|
carpet the valley,
|
||||||
|
<br/>
|
||||||
|
overcoming the thistles of blackened trees.
|
||||||
|
<br/>
|
||||||
|
|
||||||
|
The hillsides freckled, still carry October's scars.
|
||||||
|
<br/>
|
||||||
|
|
||||||
|
Around the bend, the colors recede
|
||||||
|
<br/>
|
||||||
|
to fences no more,
|
||||||
|
<br/>
|
||||||
|
but piles of rubble; vacancy.
|
||||||
|
<br/>
|
||||||
|
|
||||||
|
People once lived here, in this most beautiful place.
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
I wrote this a few months ago, just before summer started, while driving from
|
||||||
|
Santa Rosa to Napa along Highway 12. The ruins in Santa Rosa and Glen Ellen
|
||||||
|
provided stark contrast against the explosion of colors typical of a Sonoma
|
||||||
|
county spring.
|
||||||
|
|
||||||
|
Once again large wildfires blaze across Northern California, less than fifty
|
||||||
|
miles to the north in Mendocino county, at times with epic plumes of smoke
|
||||||
|
visible from my neighborhood in Santa Rosa.
|
||||||
|
|
||||||
|
We are all painfully aware of fire season.
|
|
@ -0,0 +1,171 @@
|
||||||
|
---
|
||||||
|
layout: post
|
||||||
|
title: "It's no secret where GitOps falls down"
|
||||||
|
tags:
|
||||||
|
- gitops
|
||||||
|
- infrastructure
|
||||||
|
- puppet
|
||||||
|
- jenkins
|
||||||
|
- kubernetes
|
||||||
|
---
|
||||||
|
|
||||||
|
This year I have started to see a new buzzword get thrown around, one which I
|
||||||
|
can feel especially hipstery about: GitOps. While the folks over [at
|
||||||
|
WeaveWorks](https://www.weave.works/blog/gitops-operations-by-pull-request)
|
||||||
|
have made the term fashionable in the Kubernetes ecosystem, stodgy old-timer
|
||||||
|
Puppet users might recognize the same practices they've used for a few years
|
||||||
|
now by combining [R10k and
|
||||||
|
Git](https://puppet.com/blog/git-workflows-puppet-and-r10k). In fact, I was
|
||||||
|
first introduced to the concept by [Gary
|
||||||
|
Larizza](http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/),
|
||||||
|
an absolutely loud, foul-mouthed, and wonderful hacker. The concepts Gary
|
||||||
|
blogged about I rapidly
|
||||||
|
introduced to the Jenkins project's [own Puppet-based
|
||||||
|
infrastructure](https://github.com/jenkins-infra/jenkins-infra). This blog post
|
||||||
|
isn't about how sunglasses-at-night cool all us Puppet users have been, but
|
||||||
|
instead I wished to clarify some areas where "GitOps" as a practice falls
|
||||||
|
short, and what is needed to compensate.
|
||||||
|
|
||||||
|
|
||||||
|
GitOps, in essence, is using Git as the source of truth to drive infrastructure
|
||||||
|
changes through environments using pull request and branches. Many
|
||||||
|
organizations dress it up with additional trappings which may benefit their
|
||||||
|
particular needs, but fundamentally it boils down to: infrastructure as code,
|
||||||
|
using Git for environment/pipeline management.
|
||||||
|
|
||||||
|
For example, with the Jenkins project's Puppet-based infrastructure, we follow
|
||||||
|
the following branching model sand workflow:
|
||||||
|
|
||||||
|
```
|
||||||
|
+----------------+
|
||||||
|
| pull-request-1 |
|
||||||
|
+-----------x----+
|
||||||
|
\
|
||||||
|
\ (review and merge, runs acceptance tests)
|
||||||
|
staging \
|
||||||
|
|---------------o--x--x--x---------------->
|
||||||
|
\
|
||||||
|
\ (manual merge, auto-deploys to prod hosts)
|
||||||
|
production \
|
||||||
|
|----------------------------o------------->
|
||||||
|
```
|
||||||
|
|
||||||
|
This same model works rather well for Kubernetes resources where one might
|
||||||
|
progress an application deployment through a series of stages before reaching
|
||||||
|
production.
|
||||||
|
|
||||||
|
In addition to the hopefully obvious benefits of infrastructure as code, this
|
||||||
|
approach couples nicely with ephemeral environments, and strong automated test
|
||||||
|
practices which allow developers to validate their infrastructure changes in
|
||||||
|
pull requests before reaching production, which is only a merge away!
|
||||||
|
|
||||||
|
|
||||||
|
It is not all rainbows and `:tada:` emojis. "What they don't tell you" is how
|
||||||
|
to manage secrets effectively.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
Consider a simple web application, "Hiya!", wherein a user enters an email into a form
|
||||||
|
field, clicks a button, and receives a "Hello World!" email in their inbox.
|
||||||
|
"Hiya!" is effectively stateless, but requires a
|
||||||
|
[SendGrid](https://sendgrid.com) API token in order to send the user an email.
|
||||||
|
Naturally for our "staging" environment, the application should using a
|
||||||
|
SendGrid staging API token and URL, whereas for the "production" environment it
|
||||||
|
should be using a different token backed by a very big credit card for our
|
||||||
|
high-scale email sending application.
|
||||||
|
|
||||||
|
For most organizations, it would be reasonable for all the devs to have access
|
||||||
|
to the SendGrid staging API token for testing their applications, so that can
|
||||||
|
probably be checked into the `hiya.git` repository.
|
||||||
|
|
||||||
|
What about production credentials?
|
||||||
|
|
||||||
|
A couple options come to mind:
|
||||||
|
|
||||||
|
1. Check those credentials into `hiya.git` in an encrypted form, which the
|
||||||
|
[Jenkins](https://jenkins.io/) Pipeline can properly decrypt and deploy into
|
||||||
|
the Kubernetes, or other, production environment.
|
||||||
|
1. Use a separate "shadow" development and delivery flow strictly for secrets and
|
||||||
|
credentials. This delivery pipeline would only be visible to a select few,
|
||||||
|
typically operations staff.
|
||||||
|
1. Connect some external secrets management tool (Vault, Amazon Key Management
|
||||||
|
Service, Azure Key Value)to remove any kind of "GitOps" development workflow
|
||||||
|
for secrets.
|
||||||
|
|
||||||
|
Thus far, I have not found a consistently useful approach for managing secrets
|
||||||
|
across GitOps workflows between conventional and Kubernetes-based
|
||||||
|
infrastructure.
|
||||||
|
|
||||||
|
For the Jenkins project's infrastructure, we rely on a hybrid approach:
|
||||||
|
encrypting credentials _and_ managing them in a somewhat separate "shadow"
|
||||||
|
delivery pipeline using Puppet and
|
||||||
|
[hiera](https://puppet.com/docs/puppet/5.3/hiera_intro.html) (with
|
||||||
|
hiera-eyaml).
|
||||||
|
|
||||||
|
The trade-off with the approaches 2 & 3 above, and the hybrid model the Jenkins
|
||||||
|
project utilizes is that "ops" has to be informed and involved with changes
|
||||||
|
going to production. Our involvement is typically only to make sure that a
|
||||||
|
"shadow" pull request is being developed with the production credentials
|
||||||
|
alongside the actual application deployment code. More than once I've
|
||||||
|
inadvertently deployed an application to production, only later to realize that
|
||||||
|
that application was using staging credentials because a shadow pull request
|
||||||
|
hadn't yet been merged.
|
||||||
|
|
||||||
|
Using the example flow from above as a reference, our combined workflow might
|
||||||
|
look something like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
+----------------------------------+
|
||||||
|
| pull-request-1 (requires secret) |
|
||||||
|
+--------------------------x-------+
|
||||||
|
\
|
||||||
|
\ (review and merge, runs acceptance tests)
|
||||||
|
staging \
|
||||||
|
|---------------o--x--x--x---------------->
|
||||||
|
\
|
||||||
|
\ (manual merge, auto-deploys to prod hosts)
|
||||||
|
production \
|
||||||
|
|----------------------------o---O--------->
|
||||||
|
/
|
||||||
|
/
|
||||||
|
------------------
|
||||||
|
production deploy
|
||||||
|
-----------------
|
||||||
|
secrets repository |
|
||||||
|
|-----------------o-----------------O--------------------->
|
||||||
|
/ (merge ahead of pr#1)
|
||||||
|
/
|
||||||
|
+-----------x---------------------+
|
||||||
|
| pull request for secret in pr#1 |
|
||||||
|
+---------------------------------+
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
**Not ideal**. But unfortunately I have not found a better approach for
|
||||||
|
managing secrets with the "GitOps" development flow. That said, having two
|
||||||
|
Git-based flows is a reasonable middle ground, but typically cross-repository
|
||||||
|
traffic-policing challenges do apply
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
I'm very interested to learn about how other folks are solving the problem of
|
||||||
|
managing secrets with a Git-based infrastructure deployment flow. Whether we're
|
||||||
|
talking about secrets and certificates being delivered by a tool like Puppet,
|
||||||
|
or something uploading secrets into different namespaces in Kubernetes.
|
||||||
|
|
||||||
|
|
||||||
|
Some other challenges with Git-based infrastructure delivery approaches
|
||||||
|
(GITOPS!!1), particularly with Kubernetes, which I find interesting:
|
||||||
|
|
||||||
|
* Enforcing compliance with security standards.
|
||||||
|
* Preventing configuration/state drift, which is where Puppet excels.
|
||||||
|
* Blending pipelines from multiple repositories, such that different
|
||||||
|
applications could reasonably maintain their own configurations, without
|
||||||
|
needing to run fully separate deployment pipelines.
|
||||||
|
|
||||||
|
While these challenges exist, I still fundamentally agree that "GitOps" should
|
||||||
|
be the preferred approach for auditability and tracking of state as
|
||||||
|
infrastructure and application code moves towards production.
|
||||||
|
|
||||||
|
It's not all rainbows and `:tada:` emojis, but I think we're getting there.
|
|
@ -0,0 +1,16 @@
|
||||||
|
---
|
||||||
|
layout: post
|
||||||
|
title: "The Five Stages of YAML"
|
||||||
|
tags:
|
||||||
|
- yaml
|
||||||
|
- opinion
|
||||||
|
---
|
||||||
|
|
||||||
|
1. Configuration languages are too complex; YAML is much simpler and easier to
|
||||||
|
understand.
|
||||||
|
1. Declarative YAML configuration is brilliant.
|
||||||
|
1. Lots of our things look similar, we have too much copy and pasted YAML.
|
||||||
|
1. We've written a tool which uses templates and parameters to dynamically
|
||||||
|
generate our YAML
|
||||||
|
1. The declarative YAML format now supports conditional, iteration, and inheritance
|
||||||
|
syntax; it is now turing complete.
|
Loading…
Reference in New Issue