Posts

Showing posts with the label Containers&Kubernetes

Preparing Google Cloud deployments for Docker Hub pull request limitsPreparing Google Cloud deployments for Docker Hub pull request limitsProduct Lead, Cloud CI/CDSolutions Architect

Image
Docker Hub is a popular registry for hosting public container images. Earlier this summer, Docker announced it will begin rate-limiting the number of pull requests to the service by “Free Plan” users. For pull requests by anonymous users this limit is now 100 pull requests per 6 hours; authenticated users have a limit of 200 pull requests per 6 hours. When the new rate limits take effect on November 1st, they might disrupt your automated build and deployment processes on Cloud Build or how you deploy artifacts to Google Kubernetes Engine (GKE), Cloud Run or App Engine Flex from Docker Hub.  This situation is made more challenging because, in many cases, you may not be aware that a Google Cloud service you are using is pulling images from Docker Hub. For example, if your Dockerfile has a statement like “ FROM debian:latest ”or your Kubernetes Deployment manifest has a statement like “ image: postgres:latest ” it is pulling the image directly from Docker Hub. To help you identify th...

Comparing containerization methods: Buildpacks, Jib, and DockerfileComparing containerization methods: Buildpacks, Jib, and DockerfileDeveloper Advocate

Image
As developers we work on source code, but production systems don’t run source, they need a runnable thing. Starting many years ago, most enterprises were using Java EE (aka J2EE) and the runnable “thing” we would deploy to production was a “.jar”, “.war”, or “.ear” file. Those files consisted of the compiled Java classes and would run inside of a “container” running on the JVM. As long as your class files were compatible with the JVM and container, the app would just work. That all worked great until people started building non-JVM stuff: Ruby, Python, NodeJS, Go, etc. Now we needed another way to package up apps so they could be run on production systems. To do this we needed some kind of virtualization layer that would allow anything to be run. Heroku was one of the first to tackle this and they used a Linux virtualization system called “lxc” – short for Linux Containers. Running a “containe...