AppEngine

Remember what started us down the path of managing a kubernetes cluster in the first place? No, it wasn’t our own sadistic desire to to devops in an effort to avoid building an actual project, but close. We want to be able to leverage ‘live view’ in our project, that requires websockets, which all signs pointed to not available on appengine. But wait, what’s this? App-Enggine WebSocket Support As of Feb 2019, it looks like we’re good to go. That coupled with the $30/month bill we would incur when our gcp credits ran out, this switch seems to make a lot of sense.

Clean up

• Tearing down services
  • kubectl delete service postit-web
  • gcloud compute forwarding-rules list use this to check that the loadbalancer is also removed
  • and finally the cluster of 2 VM’s gcloud container clusters delete --zone=us-central1-a postit-cluster
  • then just the database. and we’re all set to startup with app-engine

App Engine

• update KMS key/value on key for beta app. remember we tore everything down and needed to create a smaller db instance

• run mix ecto.create to instantiate new db and mix ecto.migrate

• we can see that the app in prod was able to connect and create the db by the right name in the gcp console.

• so we’ve got a new connection name and db name. I left the others the same, so I didn’t have to create all new keys for it.

• Create app.yaml file

  env: flex runtime: gs://elixir-runtime/elixir.yaml runtime_config: release_app: postit beta_settings: cloud_sql_instances: [CONNECTION-DB]

• and then just gcloud app deploy

  • but wait - had to remove the dockerfile and the cloudbuild from the directory so it would run

  • mmmm, no env’s for database name or password?? grrrrr ?

    GenServer #PID terminating ** (RuntimeError) connect raised KeyError exception: key :database not found. The exception details are hidden, as they may contain sensitive data such as database credentials. You may set :show_sensitive_data_on_connection_error to true when starting your connection if you wish to see all of the details
    • we knew it was coming.
    • with hard coding the env variables in we got it running in record time!!
    • BEHOLD IT WORKS!

• So if we update the cloudbuild to publish the docker image we’ve been making to app deploy instead of kubectl, then it will have all the compile time variables from KMS in it and run from the could build instead of locally, right?

• update docker and cloudbuild to use the newest KMS key’s for database name and variables. printenv from the docker build to confirm.

• do i need a custom start command?

• enable App Engine Admin API ?‍♀️ you’d think i’d know that by now

• change the sql directory to /cloudsql/[CONNECTION_NAME] that’s just removing the tmp/ from our KMS. Which i can just update and replace the base64 string in the cloudbuild file. so that’s rad.

At this point. For someone who is pretty vocal about not liking the devops side of things, you sure spend a lot of time working on those details.

• you make a fair point. it’s hard to argue that.
• so maybe instead i’ll try to Justify it?
• what good is a side project if you can’t get it out there?
• or if you have to manually deploy it when my make changes. How often will you actually deploy new stuff?
• Answers to these questions might be different for you, but they are a real barrier to entry for me.
• I want to as it’s most basic level, work on my project, and then pull it up on my phone after I commit changes.
• I don’t want to be building new releases locally, waiting around to manually do steps 2 and 3. I want just one step, git push that for me is the only sure fire way I will have a current release out there for me to play with on my phone.
• Then there is the sharing aspect. I want to share this project. To have other’s see it, and provide feedback, that’s a lot easier to shorten the feedback cycle when it’s out there and updated on every commit. Auto-magicly

Ok where’d we leave off?

• we’ve got cloudbuild creating our custom build. with env variables so no secrets in the code
• We hit “18:07:59.579 [error] Postgrex.Protocol (#PID) failed to connect: ** (Postgrex.Error) FATAL 53300 (too_many_connections) remaining connection slots are reserved for non-replication superuser connections”
• connection limits. lol
• which is really poetic, if you remember we struggles for days getting the unix socket connected on our local machine. LOL and this point you can’t help but laugh.
• And we’re in business. ? Post it on App Engine
• well, almost. there’s an error on “number of connections”, gigalixir made note if you’re on the free tier, then set your poolsize to 2. so we did.

And what’d we get for all that effort?

• domain mapping
• SSL
• continuous integration on git commit
• a whole crap ton of knowledge around the gcp ecosystem and for a small part we know a lot about debugging an elixir app with distillery.
• Now on to OAuth?

Postit Blog With SSL

 

Follow

• JavaScript to Elm
  • Twitter: @jstoelm
  • Email: [email protected]
• Jesse Tomchak
  • Twitter: @jtomchak

We cannot render the preview. If you use HTML tags, check if these are valid.