4 ms·

Okay. I spent a lot of time last week trying to get elixir setup on gcloud, but variables were the one thing I could never figure out and I eventually gave up.

Okay. I spent a lot of time last week trying to get elixir setup on gcloud, but variables were the one thing I could never figure out and I eventually gave up. Is there some magical way to get variables and secrets in gcloud without having to commit them to a repo?

derefr 9y ago
Deploy to Google Kubernetes Engine; `kubectl create secret`; set the env-vars of your Deployment to be derived from the secret.
- skrebbel 9y ago
  Wait, you can't put secrets in GCP without first learning Kubernetes? That's pretty messed up :/
  - derefr 9y ago
    More like, Kubernetes (and Google Kubernetes Engine) is the right level of abstraction to actually have a first-class object-type of "secret." Compute Engine is just raw IaaS, like EC2. You "store secrets" on GCE by writing them to a volume and attaching it across your cluster, or putting them in a common database. Or just pushing data onto your instances after they're up using Fabric or something. You know, just like if they were real computers. App Engine is made to be a complete and self-contained PaaS (much moreso than anything like Heroku), to the point that it doesn't really use external credentials for anything. For example, you can access BigQuery tables from App Engine without supplying any "BigQuery credentials." Oddly enough, if you do need to connect to third-party services (or, say, Google Cloud SQL) from App Engine, they recommend that you store the credentials to do so in... a BigQuery table. GAE is proprietary and weird. It's basically its own "abstract machine." Kubernetes Engine, in comparison, is exactly for the use-case of "deploying workloads" of regular potentially-stateful, potentially-long-lived POSIX apps that need things like DB connection strings passed to them. If you're a modern backend developer who burns Docker images like people 10 years ago burned CDs, Kubernetes is the service you should be using on any compute cloud you interact with. Everything else is an impedance mismatch.
    - Aduket 9y ago
      thanks for the summary.

derefr 9y ago

Deploy to Google Kubernetes Engine; `kubectl create secret`; set the env-vars of your Deployment to be derived from the secret.

skrebbel 9y ago
Wait, you can't put secrets in GCP without first learning Kubernetes? That's pretty messed up :/
- derefr 9y ago
  More like, Kubernetes (and Google Kubernetes Engine) is the right level of abstraction to actually have a first-class object-type of "secret." Compute Engine is just raw IaaS, like EC2. You "store secrets" on GCE by writing them to a volume and attaching it across your cluster, or putting them in a common database. Or just pushing data onto your instances after they're up using Fabric or something. You know, just like if they were real computers. App Engine is made to be a complete and self-contained PaaS (much moreso than anything like Heroku), to the point that it doesn't really use external credentials for anything. For example, you can access BigQuery tables from App Engine without supplying any "BigQuery credentials." Oddly enough, if you do need to connect to third-party services (or, say, Google Cloud SQL) from App Engine, they recommend that you store the credentials to do so in... a BigQuery table. GAE is proprietary and weird. It's basically its own "abstract machine." Kubernetes Engine, in comparison, is exactly for the use-case of "deploying workloads" of regular potentially-stateful, potentially-long-lived POSIX apps that need things like DB connection strings passed to them. If you're a modern backend developer who burns Docker images like people 10 years ago burned CDs, Kubernetes is the service you should be using on any compute cloud you interact with. Everything else is an impedance mismatch.
  - Aduket 9y ago
    thanks for the summary.