TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Introducing Google Cloud Container Builder

310 点作者 vgt大约 8 年前

16 条评论

alpb大约 8 年前
Disclaimer: I work at Google but I do not work on the product, so this is my personal experience.<p>I recently tried out Cloud Container Builder before it went public. I host a lot of small personal Docker projects on my private GitHub repositories and build Docker images for them using CircleCI and push them to GCR (Google Container Registry). Once you figure out how to do this with $your_favorite_CI_tool, it is easy. However it took me about an hour to build this Circle CI and I had to do some tasks like set up Service Accounts, copy keys around etc.<p>Google Container Builder eliminates this completely, you just connect your GitHub account, pick what you want to build (every commit, branch or tag) and specify the image name you want to build and forget about it forever.<p>It runs faster compared to free CI services I&#x27;ve used in the past (probably because image pulls are fast b&#x2F;c Google Networking, but I&#x27;m not sure how much CPU is allocated for builds). Also if you&#x27;re pushing to GCR, then it&#x27;ll be faster to push images as well. So overall pull&#x2F;build&#x2F;push cycle is just fast. To compare, build for a very simple image I have (base image docker.io&#x2F;library&#x2F;python) takes 3m30s on CircleCI vs 1m10s in Google Cloud Container Builder. That&#x27;s 3x faster.
评论 #13808808 未加载
评论 #13808542 未加载
评论 #13807641 未加载
评论 #13808434 未加载
nchuhoai大约 8 年前
I&#x27;m so surprised that both Docker&#x27;s as well as Google&#x27;s solution to this problem involves 0 caching.<p>Much of our container building includes fetching dependencies from various package managers which rarely changes across builds, yet takes up the majority of the build time. Most of the time thats good enough, but for cases where we want to immediately deploy a fix, it can be quite frustrating to having to spend all this time seemingly unncessarily.<p>Edit: Docker 1.13 has the new --cache-from option so it seems relatively straight-forward to do I guess?
评论 #13806861 未加载
评论 #13806854 未加载
评论 #13806748 未加载
评论 #13806838 未加载
skj大约 8 年前
Hi all, I&#x27;m on the eng team for this service. Happy to answer any questions, and I&#x27;ll do my best to monitor the threads.
评论 #13807213 未加载
评论 #13806730 未加载
评论 #13806584 未加载
评论 #13809998 未加载
评论 #13817269 未加载
评论 #13811698 未加载
评论 #13818465 未加载
评论 #13807305 未加载
评论 #13806486 未加载
评论 #13809303 未加载
评论 #13808390 未加载
评论 #13807097 未加载
noway421大约 8 年前
Just as with Amazon solution, this seems to not have caching. Baking deps into a separate image is a good solution, but oftentimes you want to rely on docker caching itself. For example docker caches `npm install` quite nicely if you split up the copying of package.json to a separate layer, which allows for a very neat flow where small app diffs result in a fast build, while adding new npm packages results in a slightly longer build. Not possible with GCCB or AWS CodeBuild.. For now, a self-managed Atlassian Bamboo instance (which can and does do caching for each worker) seems to be the best way?
评论 #13809548 未加载
bsaul大约 8 年前
With appengine exposing instances and cloud container facilitating the deployment of software packages, i wonder how long it&#x27;ll take until the two merge.
评论 #13806310 未加载
theCricketer大约 8 年前
Could someone explain specifically what problem Container Builder solves?
评论 #13806419 未加载
评论 #13806182 未加载
评论 #13808563 未加载
评论 #13806576 未加载
thejosh大约 8 年前
Does anybody know when they are launching in Australia? They have listed 2017 as the launch year, and I&#x27;m excited for launch :).
评论 #13806761 未加载
mikebannister大约 8 年前
Really interesting. Is it possible that you&#x27;ll remove the &quot;one build at a time&quot; restriction at some point? I&#x27;m imagining builds across a large org some of which would need to be run in parallel. Or am I misperceiving things in one way or another? Thanks!
评论 #13858846 未加载
hiroshi3110大约 8 年前
Before GCCB become GA, to workaround 120min&#x2F;day restriction I wrote a command line GCCB like tool. <a href="https:&#x2F;&#x2F;github.com&#x2F;hiroshi&#x2F;cb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hiroshi&#x2F;cb</a>
7ewis大约 8 年前
Haven&#x27;t tested out GCP yet, but am familiar with AWS and have played around with Docker a little.<p>Am I correct in saying that all this does is effectively a:<p>&gt;docker build &gt;docker push<p>But builds it all server side, then stores it in Google&#x27;s Container Registry?
评论 #13810231 未加载
fishnchips大约 8 年前
I&#x27;d love to see that target the market for CI&#x2F;CD tools which cost an arm and leg while offering a shiny UI but only a minor convenience. That would require an extended tutorial section and an ecosystem of plugins.
评论 #13806403 未加载
splitbrain大约 8 年前
Could I use this to build images and push them to Docker Hub? The auto build feature at Docker Hub is awfully slow and often fails. Could this be a good alternative or am I missing the point of what this is?
评论 #13810094 未加载
pm90大约 8 年前
Hah, interesting to note how much dogfooding happens at Google before they make these technologies available to outside customers. This is a really smart move on their part.
评论 #13806364 未加载
salakotolu大约 8 年前
Was just reading about this today. Didn&#x27;t know it was new.
评论 #13806530 未加载
wstrange大约 8 年前
&quot;First 120 build-minutes per day&quot; : FREE<p>Nice for Hobby projects...
评论 #13806428 未加载
评论 #13809834 未加载
howfun大约 8 年前
By seeing so much confusing Docker articles lately, I have a feeling that the Docker containers are creating much more problems than they are solving.