|
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