|
1 | 1 | ---
|
2 | 2 | title: "A Reintroduction to OpenFaaS on Nomad"
|
3 | 3 | description: Andrew Cornies reintroduces the faas-nomad provider. Learn why running OpenFaaS on Nomad is a compelling alternative to start your Serverless journey.
|
4 |
| -date: 2019-04-05 |
| 4 | +date: 2019-03-18 |
5 | 5 | image: /images/openfaas-on-nomad/abstract-blaze-bonfire-211157.jpg
|
6 | 6 | categories:
|
7 | 7 | - nomad
|
@@ -64,53 +64,58 @@ Let's look at the Vault integration more closely:
|
64 | 64 | Let's provision a Vault instance to handle the secrets API of OpenFaaS:
|
65 | 65 |
|
66 | 66 | Reference example:
|
67 |
| -https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/vault_populate.sh |
| 67 | +[https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/vault_populate.sh](https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/vault_populate.sh) |
68 | 68 |
|
69 | 69 | 1) Enable the approle auth backend in Vault:
|
70 | 70 |
|
71 |
| - `vault auth enable approle` |
| 71 | +```shell |
| 72 | +vault auth enable approle |
| 73 | +``` |
72 | 74 |
|
73 | 75 | 2) Create a policy for faas-nomad and OpenFaaS functions:
|
74 | 76 |
|
75 |
| - `vault policy write openfaas policy.hcl` |
| 77 | +```shell |
| 78 | +vault policy write openfaas policy.hcl |
| 79 | +``` |
76 | 80 |
|
77 |
| - Policy file example: https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/policy.hcl |
| 81 | + Policy file example: [https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/policy.hcl](https://raw.githubusercontent.com/hashicorp/faas-nomad/master/provisioning/scripts/policy.hcl) |
78 | 82 |
|
79 | 83 | It is important that the policy contain: create, update, delete and list capabilities that match your secret backend prefix. In this case, path "secret/openfaas/*" will work with the default configuration.
|
80 | 84 |
|
81 | 85 | Also, faas-nomad takes care of renewing it's own auth token, so we need to make sure the policy uses path "auth/token/renew-self" and has the "update" capability.
|
82 | 86 |
|
83 | 87 | 3) Setup the approle itself:
|
84 |
| - ``` |
85 |
| - curl -i \ |
86 |
| - --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
87 |
| - --request POST \ |
88 |
| - --data '{"policies": ["openfaas"], "period": "24h"}' \ |
89 |
| - https://${VAULT_HOST}/v1/auth/approle/role/openfaas |
90 |
| - ``` |
| 88 | +```shell |
| 89 | +curl -i \ |
| 90 | + --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
| 91 | + --request POST \ |
| 92 | + --data '{"policies": ["openfaas"], "period": "24h"}' \ |
| 93 | + https://${VAULT_HOST}/v1/auth/approle/role/openfaas |
| 94 | +``` |
91 | 95 | This creates the role attached to the policy we just created. The "period" property and duration is important for renewing long-running service Vault tokens.
|
92 |
| - ``` |
93 |
| - curl -i \ |
94 |
| - --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
95 |
| - https://${VAULT_HOST}/v1/auth/approle/role/openfaas/role-id |
96 |
| - ``` |
97 |
| - Produces the role_id needed for -vault_app_role_id cli argument. |
98 |
| - ``` |
99 |
| - curl -i \ |
100 |
| - --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
101 |
| - --request POST \ |
102 |
| - https://VAULT_HOST}/v1/auth/approle/role/openfaas/secret-id |
103 |
| - ``` |
| 96 | +```shell |
| 97 | +curl -i \ |
| 98 | + --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
| 99 | + https://${VAULT_HOST}/v1/auth/approle/role/openfaas/role-id |
| 100 | +``` |
| 101 | +Produces the role_id needed for -vault_app_role_id cli argument. |
| 102 | +```shell |
| 103 | +curl -i \ |
| 104 | + --header "X-Vault-Token: ${VAULT_TOKEN}" \ |
| 105 | + --request POST \ |
| 106 | + https://${VAULT_HOST}/v1/auth/approle/role/openfaas/secret-id |
| 107 | +``` |
104 | 108 | Produces the secret_id needed for -vault_app_secret_id cli argument.
|
105 | 109 |
|
106 | 110 | Let's assume the Vault parameters have been populated in the run args, and you're now running faas-nomad along with the other OpenFaaS components. Now, try out the new faas-cli secret commands:
|
107 | 111 |
|
108 |
| -``` |
109 |
| -faas-cli secret create grafana_api_token --from-literal=foo --gateway ${FAAS_GATEWAY} |
| 112 | +```shell |
| 113 | +faas-cli secret create grafana_api_token --from-literal=foo \ |
| 114 | + --gateway ${FAAS_GATEWAY} |
110 | 115 | ```
|
111 | 116 |
|
112 | 117 | Now we can use our newly created secret “grafana_api_token” in a new function we want to deploy:
|
113 |
| -``` |
| 118 | +```shell |
114 | 119 | faas-cli deploy --image acornies/grafana-annotate \
|
115 | 120 | --name grafana-annotate --secret grafana_api_token \
|
116 | 121 | --env grafana_url=http://grafana.service.consul:3000
|
|
0 commit comments