7 ms·

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

by skj 10y ago

searchfaster 10y ago
Thanks skj.. any plans of supporting containers other than docker ?
- skj 10y ago
  I really like rocket, and technically you can build and push rkt images right now, though it would require a lot of rocket knowhow. Briefly, you can run any container image as a build step with this service, including one that builds rocket containers, and including one that pushes them. But, we're not currently offering any direct support for this ability.
  - philips 10y ago
    rkt supports running Docker Images[1], Open Container Initiative (OCI) Images[2], and appc images. So, any container image this system builds will run under rkt. rkt is explicitly designed as a container engine not as a container build system. And this is because build and execute are largely separate concerns. And it leaves the door open for new build systems as demonstrated here by Google. [1] https://coreos.com/rkt/docs/latest/running-docker-images.html https://coreos.com/rkt/docs/latest/running-docker-images.htm... [2] https://github.com/opencontainers/image-spec/issues/126#issuecomment-239014209 https://github.com/opencontainers/image-spec/issues/126#issu...
- deleted 10y ago
  [deleted]
puzzle 10y ago
Is there any caching involved? In other words, what happens if I build the same source tree twice or if one line changes between one run and the next?
- skj 10y ago
  We don't currently cache anything from one build to the next. We are open to optimizations here, in the future.
  - derefr 10y ago
    In my mind, at least for custom builds, the most widely-applicable optimization would be providing the build environment with a FUSE-mounted build-cache GCS bucket. Such a mount could then be used in ways similar to the way Heroku's buildpacks use their build artifact cache directory.
  - bendavis381 10y ago
    Our Python dependencies include gensim and numpy which puts the build > 10min. Without layer caching, what can I do to get the build time down?
tjenkinsqs 10y ago
Very glad that you are offering this service. A key feature needed is speed, i.e. minimal time from check-in through build/unit & integration tests/image/deploy. Questions: - What delay can we expect from check-in to start of build (seconds, minutes?) - What kind of compute power/memory is available for the build? if I run on fast CPU vs slow CPU that makes obviously a difference. What does this service run on? - Is there a way to allocate more vertical resources (more CPU/memory)? - Can parts of the pipeline be parallelized, e.g. run certain tests in parallel (using more than one core/machine)?
- skj 10y ago
  "speed": We start most builds in under a second, but we don't currently offer an SLA. "parallelism": You can indicate any kind of concurrency topology you like with the "wait_for" field on a step: see https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... "different machines / resources": Currently it's n1-standard-1 GCE VMs. It's possible that in the future we may become more flexible.
  - tjenkinsqs 10y ago
    Thanks!
tjenkinsqs 10y ago
While some of our targets will be Google App Engine Flexible, some will be GAE standard. Can we use it with GAE standard as well?
- ravdovid 10y ago
  While we are focused on building Docker containers, you are not required to produce a container in your build. Any other built artifacts will need to be copied to persistent storage in one of your build steps.
lobster_johnson 10y ago
This looks great. One question: We're currently using Drone (the open-source self-hosted version), which allows us to define a number of parallel sidecar containers ("compose") as part of the build pipeline. We start things like PostgreSQL and Elasticsearch like this because a lot of tests need to exercise the actual data storage instead of (or in addition to) mocking/emulating them. The container builder thus doubles as a CI server, since every build needs to be tested anyway, and tests need to go through very much the same steps (install dependencies, build source and so on). Tests benefit from being run on the exact same filesystem that the final code runs on, guaranteeing that dependencies are identical. From what I can tell, such a setup is not supported by GCCB?
- skj 10y ago
  My general advice is to do integration testing after push. You say that you value the testing harness having the same set of dependencies as your deployable artifact. With GCCB, you are not limited to one image with your build - it can be any number of them. So, something like 1. build the deployable as gcr.io/project/service:${REVISION_ID} 2. build the testing harness as gcr.io/project/testing:${REVISION_ID} 3. build the db container as gcr.io/project/db:${REVISION_ID} Then, you can spin up a test environment using the ${REVISION_ID} tags, and do your integration testing there with the same nice guarantees. That all said, it's certainly possible to do fancier things within the build itself. Using the gcr.io/cloud-builders/docker build step, you can run any docker command. We haven't seen the need to directly support a docker-compose build step, but making it would be easy (different entrypoint on the docker build step) and it would automatically connect to the worker host's daemon. You can also run several of these docker build steps in parallel, or run one that does 'docker run --name=foo -d ...' and have the others run with '--link foo:foo', etc. We try not to limit the sorts of things you can do, and provide bonus features like the docker daemon's socket, service account credentials etc. You don't even need to build a container image, if you don't want to. Just provide some container images and we'll run them for you, pipe the logs back to you, and let you know how it went.
  - lobster_johnson 10y ago
    Hm, that's a bit much. In particular as various apps have a different setup (we're a microservice shop and have tons of them, although a minority needs external dependencies for tests like these). Splitting it up like that also generates a dependency, which adds a burden on an already complicated workflow. Drone just solves that so much better by keeping everything in a single, simple build file.
lobster_johnson 10y ago
How are secrets intended to be managed? E.g.: NPM auth tokens (for private NPM modules), Github tokens (e.g. for private Ruby gems or submodules), Slack webhooks, etc. I suppose one could bake that stuff into a base image, or store it in a Kubernetes secret that the build service account has access to.
- skj 10y ago
  We currently don't have direct support for secrets other than your service account's access tokens. We hope to support more arbitrary secrets in the future. As you said, you can bake things into a base image (ew) or use your credentials to fetch them from somewhere else (I suggest Cloud Storage).
  - lobster_johnson 10y ago
    The problem with uploading them somewhere is that you introduce an implicit dependency that must be documented and dealt with as part of the whole devops universe — it's just one more thing on top of a heap of other things. It's much nicer, and more secure (in terms of locking down just one thing and not having to manage multiple to be able to centralize secrets somewhere. Whereas keeping things like this close the project is of course more convenient for developers. Drone has tried two different systems, neither of which were ideal, and is working on a third one. I believe the third one also involves encrypted secrets committed to the project repo.
    - ravdovid 10y ago
      Thank you for the input -- we do recognize the importance of being able to manage secure inputs to your builds and are investigating good solutions for this.
Avaclon 10y ago
Hi, How does this work with regards to build parallelism? For examples builds that make use of outside parallel services such as ElectricAccelerator or Incredibuild?
- skj 10y ago
  GCCB does inside-VM parallelism with build steps, but the service itself does not support fan-out to multiple machines. I think of GCCB as a building block on which a fan-out product can be built on. In fact, here is some vaporware: https://github.com/skelterjohn/flargo https://github.com/skelterjohn/flargo (a 20% project that is mostly just some ideas right now) (I am skelterjohn).
cammm 10y ago
Any support currently or planned for windows container builds?
- skj 10y ago
  We recognize the demand, and we're open to trying to get things working, but currently there is no support.
ProblemFactory 10y ago
Could this be used as a more general CI service without deploying docker containers as the end result? For example to build a C++ project, run tests, and publish resulting artefacts (binaries, tarballs) in some release repository?
- skj 10y ago
  Absolutely. Under the covers, GCCB is an arbitrary execution engine - we run a series of containers for you. On top of that, we provide a lot of nice dressing to make it convenient and easy to build containers. https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... and https://cloud.google.com/container-builder/docs/api/custom-build-steps https://cloud.google.com/container-builder/docs/api/custom-b... are documentation on how to use and create your own custom build steps. Additionally, your build steps have access to the credentials of the service account used to run your build, so pushing to Cloud Storage, for instance, is straightforward (use the gsutil build step).
shostack 10y ago
I'm not quite a novice but not a real developer by any means. I'm interested in learning more about containers and using them with my RoR side projects. Is this new product a good place to start that would be relatively pain free for someone new to containers?
- skj 10y ago
  If you're new to containers, I recommend starting by learning all about Dockerfiles. You can build them on your own machine, or with GCCB (using the `gcloud` command-line tool). Dockerfiles make it challenging to keep your build-time environment separate from the run-time environment. For instance, you need the JDK to build your java app, but only the much smaller JRE to run it. Or maybe you want to use bazel.io for building, and have a completely different base image in mind for your deployment. Or maybe you want to bring in a unit testing harness and not publish the image unless all the tests pass. Once these issues start to matter, GCCB has a great story. In essence, GCCB runs a series of containers with your source mounted in. So, you can run one step to run unit tests, another to build a binary, and a third to package everything into a container image. GCCB also will build as many containers as you want in a single execution, so if you have several microservices that are all versioned together, you can build them at the same time and give them a `:${REVISION_ID}` tag - useful for production rollouts.
hiroshi3110 10y ago
You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/ https://developer.github.com/v3/repos/statuses/
- skj 10y ago
  We don't have any direct support of GitHub status updates. You can make whatever requests from within the build (presumably at the end), but we don't (yet!) have a supported way to get secrets into the build for access to POST the new status. GCCB will also publish on Cloud Pub/Sub when the build's status changes (including when it goes to "SUCCESS" or "FAILURE"), and you can tell Cloud Pub/Sub to make POST requests with that data, but the format is not flexible so it might not work out for GitHub status updates.
  - hiroshi3110 10y ago
    Thanks. On build failure the last step are not executed I think. So I'll check cloud pub/sub. BTW, are there any community or (public) support channel out there? You know a HN thread is not a permanent place. I searched on SO, but no label of google cloud container builder yet. http://stackoverflow.com/search?q=google+cloud+container+builder http://stackoverflow.com/search?q=google+cloud+container+bui...
tonglil 10y ago
The pricing page doesn't mention any information about data ingress/egress. Care to clarify please?
- skj 10y ago
  The cloudbuild service operates some other services on your behalf, and their relevant charges apply. This most notably includes Cloud Storage (GCR is backed by Cloud Storage). If you use 'gcloud container builds submit' to kick off a build, Cloud Storage is used to get the source in as well.

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

by skj 10y ago

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

searchfaster 10y ago

Thanks skj.. any plans of supporting containers other than docker ?

skj 10y ago
I really like rocket, and technically you can build and push rkt images right now, though it would require a lot of rocket knowhow. Briefly, you can run any container image as a build step with this service, including one that builds rocket containers, and including one that pushes them. But, we're not currently offering any direct support for this ability.
- philips 10y ago
  rkt supports running Docker Images[1], Open Container Initiative (OCI) Images[2], and appc images. So, any container image this system builds will run under rkt. rkt is explicitly designed as a container engine not as a container build system. And this is because build and execute are largely separate concerns. And it leaves the door open for new build systems as demonstrated here by Google. [1] https://coreos.com/rkt/docs/latest/running-docker-images.html https://coreos.com/rkt/docs/latest/running-docker-images.htm... [2] https://github.com/opencontainers/image-spec/issues/126#issuecomment-239014209 https://github.com/opencontainers/image-spec/issues/126#issu...
deleted 10y ago
[deleted]

puzzle 10y ago

Is there any caching involved? In other words, what happens if I build the same source tree twice or if one line changes between one run and the next?

skj 10y ago
We don't currently cache anything from one build to the next. We are open to optimizations here, in the future.
- derefr 10y ago
  In my mind, at least for custom builds, the most widely-applicable optimization would be providing the build environment with a FUSE-mounted build-cache GCS bucket. Such a mount could then be used in ways similar to the way Heroku's buildpacks use their build artifact cache directory.
- bendavis381 10y ago
  Our Python dependencies include gensim and numpy which puts the build > 10min. Without layer caching, what can I do to get the build time down?

tjenkinsqs 10y ago

Very glad that you are offering this service. A key feature needed is speed, i.e. minimal time from check-in through build/unit & integration tests/image/deploy. Questions: - What delay can we expect from check-in to start of build (seconds, minutes?) - What kind of compute power/memory is available for the build? if I run on fast CPU vs slow CPU that makes obviously a difference. What does this service run on? - Is there a way to allocate more vertical resources (more CPU/memory)? - Can parts of the pipeline be parallelized, e.g. run certain tests in parallel (using more than one core/machine)?

skj 10y ago
"speed": We start most builds in under a second, but we don't currently offer an SLA. "parallelism": You can indicate any kind of concurrency topology you like with the "wait_for" field on a step: see https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... "different machines / resources": Currently it's n1-standard-1 GCE VMs. It's possible that in the future we may become more flexible.
- tjenkinsqs 10y ago
  Thanks!

tjenkinsqs 10y ago

While some of our targets will be Google App Engine Flexible, some will be GAE standard. Can we use it with GAE standard as well?

ravdovid 10y ago
While we are focused on building Docker containers, you are not required to produce a container in your build. Any other built artifacts will need to be copied to persistent storage in one of your build steps.

lobster_johnson 10y ago

This looks great. One question: We're currently using Drone (the open-source self-hosted version), which allows us to define a number of parallel sidecar containers ("compose") as part of the build pipeline. We start things like PostgreSQL and Elasticsearch like this because a lot of tests need to exercise the actual data storage instead of (or in addition to) mocking/emulating them. The container builder thus doubles as a CI server, since every build needs to be tested anyway, and tests need to go through very much the same steps (install dependencies, build source and so on). Tests benefit from being run on the exact same filesystem that the final code runs on, guaranteeing that dependencies are identical. From what I can tell, such a setup is not supported by GCCB?

skj 10y ago
My general advice is to do integration testing after push. You say that you value the testing harness having the same set of dependencies as your deployable artifact. With GCCB, you are not limited to one image with your build - it can be any number of them. So, something like 1. build the deployable as gcr.io/project/service:${REVISION_ID} 2. build the testing harness as gcr.io/project/testing:${REVISION_ID} 3. build the db container as gcr.io/project/db:${REVISION_ID} Then, you can spin up a test environment using the ${REVISION_ID} tags, and do your integration testing there with the same nice guarantees. That all said, it's certainly possible to do fancier things within the build itself. Using the gcr.io/cloud-builders/docker build step, you can run any docker command. We haven't seen the need to directly support a docker-compose build step, but making it would be easy (different entrypoint on the docker build step) and it would automatically connect to the worker host's daemon. You can also run several of these docker build steps in parallel, or run one that does 'docker run --name=foo -d ...' and have the others run with '--link foo:foo', etc. We try not to limit the sorts of things you can do, and provide bonus features like the docker daemon's socket, service account credentials etc. You don't even need to build a container image, if you don't want to. Just provide some container images and we'll run them for you, pipe the logs back to you, and let you know how it went.
- lobster_johnson 10y ago
  Hm, that's a bit much. In particular as various apps have a different setup (we're a microservice shop and have tons of them, although a minority needs external dependencies for tests like these). Splitting it up like that also generates a dependency, which adds a burden on an already complicated workflow. Drone just solves that so much better by keeping everything in a single, simple build file.

lobster_johnson 10y ago

How are secrets intended to be managed? E.g.: NPM auth tokens (for private NPM modules), Github tokens (e.g. for private Ruby gems or submodules), Slack webhooks, etc. I suppose one could bake that stuff into a base image, or store it in a Kubernetes secret that the build service account has access to.

skj 10y ago
We currently don't have direct support for secrets other than your service account's access tokens. We hope to support more arbitrary secrets in the future. As you said, you can bake things into a base image (ew) or use your credentials to fetch them from somewhere else (I suggest Cloud Storage).
- lobster_johnson 10y ago
  The problem with uploading them somewhere is that you introduce an implicit dependency that must be documented and dealt with as part of the whole devops universe — it's just one more thing on top of a heap of other things. It's much nicer, and more secure (in terms of locking down just one thing and not having to manage multiple to be able to centralize secrets somewhere. Whereas keeping things like this close the project is of course more convenient for developers. Drone has tried two different systems, neither of which were ideal, and is working on a third one. I believe the third one also involves encrypted secrets committed to the project repo.
  - ravdovid 10y ago
    Thank you for the input -- we do recognize the importance of being able to manage secure inputs to your builds and are investigating good solutions for this.

Avaclon 10y ago

Hi, How does this work with regards to build parallelism? For examples builds that make use of outside parallel services such as ElectricAccelerator or Incredibuild?

skj 10y ago
GCCB does inside-VM parallelism with build steps, but the service itself does not support fan-out to multiple machines. I think of GCCB as a building block on which a fan-out product can be built on. In fact, here is some vaporware: https://github.com/skelterjohn/flargo https://github.com/skelterjohn/flargo (a 20% project that is mostly just some ideas right now) (I am skelterjohn).

cammm 10y ago

Any support currently or planned for windows container builds?

skj 10y ago
We recognize the demand, and we're open to trying to get things working, but currently there is no support.

ProblemFactory 10y ago

Could this be used as a more general CI service without deploying docker containers as the end result? For example to build a C++ project, run tests, and publish resulting artefacts (binaries, tarballs) in some release repository?

skj 10y ago
Absolutely. Under the covers, GCCB is an arbitrary execution engine - we run a series of containers for you. On top of that, we provide a lot of nice dressing to make it convenient and easy to build containers. https://cloud.google.com/container-builder/docs/api/build-steps https://cloud.google.com/container-builder/docs/api/build-st... and https://cloud.google.com/container-builder/docs/api/custom-build-steps https://cloud.google.com/container-builder/docs/api/custom-b... are documentation on how to use and create your own custom build steps. Additionally, your build steps have access to the credentials of the service account used to run your build, so pushing to Cloud Storage, for instance, is straightforward (use the gsutil build step).

shostack 10y ago

I'm not quite a novice but not a real developer by any means. I'm interested in learning more about containers and using them with my RoR side projects. Is this new product a good place to start that would be relatively pain free for someone new to containers?

skj 10y ago
If you're new to containers, I recommend starting by learning all about Dockerfiles. You can build them on your own machine, or with GCCB (using the `gcloud` command-line tool). Dockerfiles make it challenging to keep your build-time environment separate from the run-time environment. For instance, you need the JDK to build your java app, but only the much smaller JRE to run it. Or maybe you want to use bazel.io for building, and have a completely different base image in mind for your deployment. Or maybe you want to bring in a unit testing harness and not publish the image unless all the tests pass. Once these issues start to matter, GCCB has a great story. In essence, GCCB runs a series of containers with your source mounted in. So, you can run one step to run unit tests, another to build a binary, and a third to package everything into a container image. GCCB also will build as many containers as you want in a single execution, so if you have several microservices that are all versioned together, you can build them at the same time and give them a `:${REVISION_ID}` tag - useful for production rollouts.

hiroshi3110 10y ago

You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/ https://developer.github.com/v3/repos/statuses/

skj 10y ago
We don't have any direct support of GitHub status updates. You can make whatever requests from within the build (presumably at the end), but we don't (yet!) have a supported way to get secrets into the build for access to POST the new status. GCCB will also publish on Cloud Pub/Sub when the build's status changes (including when it goes to "SUCCESS" or "FAILURE"), and you can tell Cloud Pub/Sub to make POST requests with that data, but the format is not flexible so it might not work out for GitHub status updates.
- hiroshi3110 10y ago
  Thanks. On build failure the last step are not executed I think. So I'll check cloud pub/sub. BTW, are there any community or (public) support channel out there? You know a HN thread is not a permanent place. I searched on SO, but no label of google cloud container builder yet. http://stackoverflow.com/search?q=google+cloud+container+builder http://stackoverflow.com/search?q=google+cloud+container+bui...

tonglil 10y ago

The pricing page doesn't mention any information about data ingress/egress. Care to clarify please?

skj 10y ago
The cloudbuild service operates some other services on your behalf, and their relevant charges apply. This most notably includes Cloud Storage (GCR is backed by Cloud Storage). If you use 'gcloud container builds submit' to kick off a build, Cloud Storage is used to get the source in as well.