Elixir with AppEngine

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 <0.1713.0> 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: jesse@jstoelm.com Jesse Tomchak Twitter: @jtomchak We cannot render the preview. If you use HTML tags, check if these are valid.

You can listen to Elixir with AppEngine online on Radio and Podcast. Open the player on this page to stream the available audio.

Elixir with AppEngine is an episode from Javascript to Elm by Jesse Tomchak.

This episode is 23:14 long.

This episode was published on Jul 11, 2019.

Yes. Use the heart button on the episode page to add it to your favorite episodes list.

Yes. This page shows related episodes from Javascript to Elm when more episodes are available from the podcast feed.