Point-and-click continuous deployment with Cloud Run
ฝัง
- เผยแพร่เมื่อ 22 ก.ค. 2024
- Code for this episode → goo.gle/3qrdsOH
Blog post for this episode → goo.gle/3qGzyND
If you’re continuously making changes to your applications code, you have to make sure that your application is also continuously deploying these changes. In this episode of Serverless Expeditions Extended, we show you how to continuously deploy new changes to your code via Cloud Run, Cloud Build, and GitHub using Cloud Buildpacks (no Dockerfile required!). Watch to learn how you can trigger deployments everytime you push a new version of your code!
Chapters:
0:00 - Intro
1:06 - Setting up the Cloud Run service
2:30 - Connecting with Github
4:15 - Using a buildpack
8:35 - Building and deploying the Cloud Run service
11:58 - Push new code, which results in an automatic build and deploy
Checkout more episodes of Serverless Expeditions → goo.gle/ServerlessExpeditions
Subscribe to get all the episodes as they come out → goo.gle/GCP
#ServerlessExpeditions #ServerlessExpeditionsExtended #CloudRun
Product:Cloud - Compute - Cloud Run, Cloud - Developer Tools - Cloud Build; fullname: Martin Omander, Katie McLaughlin; - วิทยาศาสตร์และเทคโนโลยี
Have questions about serverless architectures?
Tune into our #AskGoogleCloud premiere on Friday, March 12 10AM PT for answers and a chance to chat live with Google Cloud’s serverless experts → goo.gle/3tbKO4K
I hate the fact that this is so under-rated...
There are less than 500 views... this should be having like 5 million views... I have no idea why web-developers are not focusing on this... I deploy apps/services on Cloud Run like zillion times a day and continue adding many new services every few days (sometimes even hours) - quick POCs, background-jobs, APIs, webhook-handlers and what not... and all thanks to Martin and all the people involved with him.. . much thanks man... really respect the stuff that you do and for taking time out to create these videos..
Another great informative and easy to follow video guys! The timing is perfect, timestamps are super helpful and you two presenting it in a way that is ‘digest-able’. Hoping to see the next explainer video about cloud run for anthos. Thanks again Martin and Katie!
Tried cloud run recently and it feels great 😊
These videos are GREAT! The GCP world can be quite intimidating for newbies.
questions for the next episode:
- what's about unit/integration tests?
- what's about canary?
- what if I have multiple services?
- databases: access, secrets, and DB schema migration?
- how to get access to cloud storage?
- how to troubleshoot?
- what's about monitoring (logs, metrics, traces)?
Thank you for those *excellent* questions, Artem! I'm writing them down so we can answer them in future episodes.
hey they should introduce a button next to the like button called the "Awesome" button!! Like is just not enough for content like this !! love it, Keep it coming, thanks :)
Thank you, Harshvardhan! Comments like yours keep us going.
good job.
Martin - Could you please create a video describing the "Add Trigger" button (at 8:40) and use the PubSub notifier option to send a Slack message whenever there is a successful or failed deployment (if that is possible).
Martin has another episode where he discusses Webhooks: th-cam.com/video/tsKZ_u_uIAs/w-d-xo.html Hope this helps!
Cool stuff, thank you. One query, how can we reduce the build and deploy time if we are making small changes especially during unit testing and initial code build ?
Here is how I do it. When I'm developing on my local machine and when I'm running unit tests, I run the code outside of any container. In NodeJS the command is "node index.js" or similar. If you're running a Python Flask app, you'd run something like "flask --app hello run". The server will start listening for HTTP connections almost instantly. There are similar commands to start servers in other languages. When I'm happy with the code and I need a break, I commit it, which triggers an automatic build and test in the cloud.
What if I have multiple services and while committing my code I want to have an exclusion filter for the services files that should not be deployed and only the intended service should get redeployed?
I would probably do it with GitHub tags, where there is one tag per Cloud Run service. Cloud Build can be triggered when you push to a GitHub tag that matches a regular expression. For example, if the pushed tag contains "website", you run a build file that only builds and deploys the website.
How is cloud run charged as compared to Kubernetes Engine deploying your docker container yourself?
With Kubernetes Engine you pay per hour that your cluster is available to handle traffic. With Cloud Run you pay for the time that your service is handling a request, that is the time between when a request is received and when the response has been sent.
This is the high-level difference. For details, check the pricing pages of the two products. Some applications will cost less to run on Kubernetes Engine, while others will cost less on Cloud Run.
For a frontend project when building my nextjs and reacted I can’t detect the environment variables even though I specified them on cloud run service UI and cloudbuild UI and I’m using continuous deployment with git , how can I go about fixing this ?
Hi Mashaole! Hopefully the answers to your question on Reddit resolved the problem.
Is it possible with this kind of continuous deployment to run tests before deploying and if the tests succeed run the deployment ?
Great question! We just published a video that shows an example of that. Search TH-cam for "Continuous integration for Cloud Run" and you will find it.
I'm curious if you have also a database or an admin how to handle this? And also how you can use a real domain! Thanks for showing some real examples.
Databases: We have another video which shows how to incorporate database migrations as part of Cloud Build th-cam.com/video/Pk21gaNO6ag/w-d-xo.html If using Buildpacks, you'd have to edit the generated cloudbuild.yaml to add this functionality, but it is possible!
Domains: You can map domains to Cloud Run services cloud.google.com/run/docs/mapping-custom-domains
In the build history logs I'm getting: Your build failed to run: generic::invalid_argument: invalid build: invalid image name
How the $PORT get mapped, I didn't saw the value
The PORT environment variable is set by Cloud Run automatically when the service is started. Usually it's set to 8080 but you should always make sure your running app service listens on port $PORT. i.e. don't hard code your HTTP service to listen on a particular port.
Another point is that $PORT is used internally inside the running container. In the video example the running web service was accessed using standard HTTP/HTTPS ports 80/443 but inside the container it was mapped to $PORT (Usually 8080). If you click your running service and go to the tab marked YAML you will see the underlying configuration - search for containerPort:
Better to use your Google remote desktop next time 😉
music is much louder than the speech
Free?
I guess if your site has very low traffic, then it is almost free
Hey google