4 ms·

Could someone explain specifically what problem Container Builder solves?

fishnchips 10y ago
I'd imagine it's the same problem companies like Circle CI or Codeship solve with their Docker-focused products - testing, building and deploying containers.
- kellyjandrews 10y ago
  Codeship here again ;). We love when Google releases new products - it tends to improve the entire space in general. Our take is that Google Cloud Container Builder will fit in nicely with the Google ecosystem, but Codeship is trying to solve a different problem by being platform agnostic, and flexible enough to solve the holistic CI/CD workflow.
t0mk 10y ago
I think it's sort of container building as a service. It moves the burden of building Docker container from your laptop (or from your CI tool) to the GCE. It takes away the docker push, as it goes straight to the GCE registry (I guess). So if you need to do docker build too often, or maybe your container-release process feels a bit quirky, you might want to do it with the container builder. It doesn't seem too ground-breaking, people probably already have it automated somehow, or they use sth from Docker hub (https://docs.docker.com/docker-hub/builds/#remote-build-triggers https://docs.docker.com/docker-hub/builds/#remote-build-trig...), or quay.
- skj 10y ago
  In addition to the "typical" kinds of builds you'll get with existing services (ie run 'docker build' and 'docker push' for me), we offer a flexible and powerful configuration language: https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... One of the goals is to make it easy to separate the build-time environment from the run-time environment. eg, keep the JDK out of your deployable. We do this by letting you choose arbitrary container images to run with your source volume-mounted in. We provide some simple ones, like one that runs the 'docker' CLI, and we take care of authenticated docker pushes to GCR. But, you can use whatever you like as a builder.
  - t0mk 10y ago
    I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares? I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2017? For these goodies, you get a nice piece of vendor lock-in.
    - skj 10y ago
      The difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources. Additionally, less in your deployable is better from a security standpoint. re lock-in: We're definitely cognizant of lock-in issues, and were trying to make it as friendly as possible. In the end, our service is running a series of containers with your source mounted in. If you really want out, replicating this process is straightforward.
      - tracker1 10y ago
        Agreed, my node builds tend to build to a ./dist including a separate package.json with all test/dev bits completely removed. From there I pretty much use the -onbuild containers from the dist/ path.
user5994461 10y ago
Lack of competition to build Docker images.
philip1209 10y ago
The problem is that it's tough to push code and have it just start running on a server. Docker makes packaging and running easy. Google has docker hosting. There's still a missing intermediary of building and registering the container, and this seems to solve that need.

I'd imagine it's the same problem companies like Circle CI or Codeship solve with their Docker-focused products - testing, building and deploying containers.

kellyjandrews 10y ago
Codeship here again ;). We love when Google releases new products - it tends to improve the entire space in general. Our take is that Google Cloud Container Builder will fit in nicely with the Google ecosystem, but Codeship is trying to solve a different problem by being platform agnostic, and flexible enough to solve the holistic CI/CD workflow.

t0mk 10y ago

I think it's sort of container building as a service. It moves the burden of building Docker container from your laptop (or from your CI tool) to the GCE. It takes away the docker push, as it goes straight to the GCE registry (I guess). So if you need to do docker build too often, or maybe your container-release process feels a bit quirky, you might want to do it with the container builder. It doesn't seem too ground-breaking, people probably already have it automated somehow, or they use sth from Docker hub (https://docs.docker.com/docker-hub/builds/#remote-build-triggers https://docs.docker.com/docker-hub/builds/#remote-build-trig...), or quay.

skj 10y ago
In addition to the "typical" kinds of builds you'll get with existing services (ie run 'docker build' and 'docker push' for me), we offer a flexible and powerful configuration language: https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... One of the goals is to make it easy to separate the build-time environment from the run-time environment. eg, keep the JDK out of your deployable. We do this by letting you choose arbitrary container images to run with your source volume-mounted in. We provide some simple ones, like one that runs the 'docker' CLI, and we take care of authenticated docker pushes to GCR. But, you can use whatever you like as a builder.
- t0mk 10y ago
  I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares? I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2017? For these goodies, you get a nice piece of vendor lock-in.
  - skj 10y ago
    The difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources. Additionally, less in your deployable is better from a security standpoint. re lock-in: We're definitely cognizant of lock-in issues, and were trying to make it as friendly as possible. In the end, our service is running a series of containers with your source mounted in. If you really want out, replicating this process is straightforward.
    - tracker1 10y ago
      Agreed, my node builds tend to build to a ./dist including a separate package.json with all test/dev bits completely removed. From there I pretty much use the -onbuild containers from the dist/ path.

user5994461 10y ago

Lack of competition to build Docker images.

philip1209 10y ago

The problem is that it's tough to push code and have it just start running on a server. Docker makes packaging and running easy. Google has docker hosting. There's still a missing intermediary of building and registering the container, and this seems to solve that need.