4 ms·

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 ta

by 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.

by t0mk 10y ago

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.