Instana prides itself in being the first Observability tool to launch support of Google Cloud Run via a Cloud Native Buildpack. The Instana Cloud Native Buildpack for Cloud Run makes adding Instana monitoring to your container images built using Google Cloud Buildpacks a breeze.
Challenges of shipping containers
I have always found that Onsi Fakhouri’s “cloud-native haiku” goes to the heart of what deploying cloud-native code should be:
“here is my source code
run it on the cloud for me
i do not care how”
The cloud-native haiku gives us a glimpse into a world with such high-level abstractions for your platforms, that all you really care about is your logic.
In reality, however, your application is only a fraction of the code you actually ship to container-based platforms. The deployment of reliable applications in production requires additional capabilities baked into your containers, like correctly dividing the available memory across different aspects of your application (yes, Java Virtual Machine, I am looking at your bajillion different, poorly-understood memory settings!) or observability features like installing and configuring the collectors of your favorite Observability tool.
Beyond functional requirements for your application, there are other aspects you should keep in mind when packaging applications into containers: reproducibility (i.e., get the very same bits every time you execute the build), optimizing image size for performance, security (including, but not limited to, having as little code as possible in your container), and more.
All in all, crafting container images that package your application is a chore that would almost universally be better delegated to some automation. And Cloud Native Buildpacks are exactly one such automation!
Cloud Native Buildpacks
Cloud Native Buildpacks are the latest incarnation of the buildpack concept originally stemming with Heroku, and later picked up by Cloud Foundry: the idea is that there is automation that, given your application code or a runtime-specific packaging like a JAR file, will add around it all that is needed for your application to run in a production-ready fashion. Taking, as an example, a Java application, the Cloud Native Buildpacks will:
- Ensure there is a Java Virtual Machine in the container, and that it is updated and patched to the latest & greatest
- Ensure that the memory settings are reasonable given, for example, an estimation of how many thread the runtime is going to use
- Enable and configure functionality needed to achieve observability like JMX or (better) Instana tracing!
How hard is it to get all these goodies? Turns out, the pack utility makes it super easy:
pack build <image-name> --builder gcr.io/buildpacks/builder
The command above instructs pack to take the Google Cloud Builder and all the buildpacks it ships to create a container image from your code. The output is a container image that you can push to a container registry and, from there, deploy onto Cloud Run. Pack is also readily available in Continuous Integration / Continuous Delivery tools like CircleCI, GitLab and Tekton.
Instana Buildpack for Google Cloud Run
As we promised when introducing our Google Cloud Run support, we are releasing support for a Cloud Native Buildpack that further streamlines the already easy setup of the Instana collectors for Cloud Run. All it takes to use the Instana Buildpack for Google Cloud Run is the following command:
pack build <image-name> \ --buildpack from=builder \ --buildpack containers.instana.io/instana/release/google/buildpack \ --builder gcr.io/buildpacks/builder
With respect to the usage of just the buildpacks shipped by the Google Cloud Builder shown previously, this time the resulting image will comprise Instana tracing provided over the Instana buildpack
alongside the buildpacks shipped within the builder itself, as specified with
option. This command works for your .NET Core, Node.js and Java applications, whether built with Maven or Gradle: the Instana buildpack will automatically detect which type of application is being packaged, and set up the right instrumentation.
After having built the container image, you can push your Google Cloud Run service with a command like:
gcloud run deploy <service-name> \ --project <gcp-project-name> --image <image-name> \ --set-env-vars=INSTANA_ENDPOINT_URL=<instana_url>,INSTANA_AGENT_KEY=<instana_agent_key>
See? No manually editing Dockerfiles. No shell scripting. Just your application’s code, Cloud Native Buildpacks, and immediate, awesome value!
Cloud Native Buildpacks solve the hairy problem of packaging your applications into container images, giving you access to best-practice container image tooling with a streamlined developer experience. And since at Instana we love nothing better than streamlined developer experiences, we jumped at the opportunity of further simplifying the way to enable monitoring of your Cloud Run workloads with the Instana Buildpack for Google Cloud Run.
It has never been easier to reap the benefits of Instana’s distributed tracing on Google Cloud Run. Get started today monitoring your Cloud Run applications using the simple steps above. Not an Instana customer just yet? A free trial of Instana, no string attached, is just one click away.
- Precise sizing of a Java Virtual Machine is nigh impossible, as each thread will get a certain amount of memory allocated to it outside of the heap, and there is no setting to limit how many threads is a Java Virtual Machine allowed to spin up. In my experience, the Java Memory Calculator is by far the best facility to configure JVMs right, and it has been ported to Paketo’s Java Buildpack, which is used by the Google Cloud Buildpacks builder.