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!
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)?
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).
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.
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 :)
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.
Databases: We have another video which shows how to incorporate database migrations as part of Cloud Build ua-cam.com/video/Pk21gaNO6ag/v-deo.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
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 ?
Great question! We just published a video that shows an example of that. Search UA-cam for "Continuous integration for Cloud Run" and you will find it.
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.
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:
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!
These videos are GREAT! The GCP world can be quite intimidating for newbies.
Tried cloud run recently and it feels great 😊
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.
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: ua-cam.com/video/tsKZ_u_uIAs/v-deo.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.
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.
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.
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 ua-cam.com/video/Pk21gaNO6ag/v-deo.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
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 UA-cam for "Continuous integration for Cloud Run" and you will find it.
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.
In the build history logs I'm getting: Your build failed to run: generic::invalid_argument: invalid build: invalid image name
good job.
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