11 ms·

GitLab Container Registry

449 points by martgnz 10y ago

Fenntrek 10y ago
Interesting move. Seems Gitlab are moving fairly fast (compared to competition) and going for that all in one ecosystem (If you want it) from SCM to deployment with the range of products they've introduced.
- ayufan 10y ago
  We are thinking big. The integrated Container Registry is part of our plan. We will soon have an integrated deployments with easy to access environments. We also plan to introduce manual actions on pipelines allowing you to execute arbitary things, ex. promote to production, but also merge it back to the master. https://gitlab.com/gitlab-org/gitlab-ce/issues/17009 https://gitlab.com/gitlab-org/gitlab-ce/issues/17009 https://gitlab.com/gitlab-org/gitlab-ce/issues/17010 https://gitlab.com/gitlab-org/gitlab-ce/issues/17010
lukebennett 10y ago
Fantastic, Gitlab are absolutely nailing it at the moment. Don't think there's any other hosted service offering so many CI/CD features for free under one roof. It feels like what Github did for SCM, Gitlab are doing for CI.
- sytse 10y ago
  Thanks Luke! We'll try to keep this going. We're working on deployment environments for our next release so you can see what is deployed in each environment. After that we can do deployments that need to be confirm manually.
  - jstsch 10y ago
    Wow, that's great news. Exactly what we are looking for. I was investigating to use GitLab CI to build, and then only deploy commits with a certain tag, but a dedicated workflow for deployments is much more convenient and less error-prone.
    - sytse 10y ago
      Glad to hear that. By the way, the 'only deploy tags' strategy is already possible today if you want to do it that way.
- FireBeyond 10y ago
  I agree, this is awesome. Their post yesterday hinted at something, and I honestly didn't think it would be this exciting. I can't wait to use it.
  - sytse 10y ago
    Thanks, glad you like it. BTW I wonder how many people understood our hint yesterday: "We almost can't _contain_ our excitement about how our announcement on Monday will _register_ with you!".
    - lukebennett 10y ago
      Heh, I didn't read the hint until after the registry announcement, but saw what you did and appreciated it with the benefit of hindsight!
nikolay 10y ago
At this pace of innovation, GitHub will soon be a part of the history! GitHub has done a tremendous job with forking and pull requests, but, at least recently, they've acted disorientedly! I hope they get back into shape!
- r3bl 10y ago
  I really don't know what to hope for. All that I do now that I really enjoy watching what looks like a full on feature battle between GitLab and GitHub going on at this moment. As a guy who uses both (GitLab for my job, GitHub personally), I feel like I'm getting the best of both worlds. Although, to be perfectly honest, it feels to me like, at this point of the "feature battle", GitLab started embracing and actually improving every single thing I liked about GitHub to the point where I'm questioning my stay on GitHub for personal projects.
  - andromeduck 10y ago
    now if only they could get gitlab.com page loads consistently under 1 second... x_x
    - sytse 10y ago
      Yes, we should fix the slow page loads on GitLab.com. We're working on it in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42 I'm sorry for the current slowness.
    - recuter 10y ago
      This is my first week at Gitlab. I've joined along with a few other people (one of whom has a great big bushy beard) to specifically make you happy. There are interesting challenges that currently make this none trivial but expect things to improve greatly in the near future.
    - nikolay 10y ago
      Yup! It supposedly is written in a much more efficient language, but it severely slower than GitHub and Bitbucket.
davexunit 10y ago
Awesome, a new place to host your unpatched, opaque disk images!
- moondev 10y ago
  https://imagelayers.io https://imagelayers.io
- sytse 10y ago
  I think the patching of Docker container images is a big problem. We try to provide a completely automated flow in GitLab using CI, CD, and the container registry. I would love to have a big button that says 'update all my containers'. I've made an issue https://gitlab.com/gitlab-org/gitlab-ee/issues/592 https://gitlab.com/gitlab-org/gitlab-ee/issues/592
  - davexunit 10y ago
    The problem is that Docker, and more generally using stacks of binary disk images, is fundamentally flawed with respect to security and reproducibility. It's nontrivial to inspect these images for vulnerabilities because there is nothing that specifies the precise set of software that is in that image. Some stuff is compiled from source, some stuff is installed via one or more package managers, each of which may bundle additional software that one may not know about if they didn't inspect each piece of software carefully. Furthermore, one cannot even verify the image reasonably because the results are different depending on when it was built. In short, container images as popularized by Docker are insecure by design.
    - justinsaccount 10y ago
      Can I play too? The problem is that unix, and more generally any operating system, is fundamentally flawed with respect to security and reproducibility. It's nontrivial to inspect these installations for vulnerabilities because there is nothing that specifies the precise set of software that is in that installation. Some stuff is compiled from source, some stuff is installed via one or more package managers, each of which may bundle additional software that one may not know about if they didn't inspect each piece of software carefully. Furthermore, one cannot even verify the installation reasonably because the results are different depending on when it was installed. In short, operating systems are insecure by design.
andrewmunsell 10y ago
Everyone at GitLab has been doing an amazing job shipping some really cool features. I'm really looking forward to trying out the new container registry and move away from my hack-y solution that I use right now to build Docker images on my own VM, and move back to the shared runners :)
- sytse 10y ago
  Thanks Andrew, I hope your move goes smoothly. We want to allow everyone to go frictionless from idea to production. We're extending GitLab so this can be done simply without having to script things together yourself.
connorshea 10y ago
Kind of unrelated, but I'm super happy to be working at GitLab. Nearly everything we do is out in the open, and most features are available in CE, which is fully open source (https://gitlab.com/gitlab-org/gitlab-ce https://gitlab.com/gitlab-org/gitlab-ce). I've wanted great, open source tools that don't look like dung for a long long time, and GitLab is definitely reaching that goal. Can't help but gush about the product we're building. :D Here are some of my favorite upcoming features: https://gitlab.com/gitlab-org/gitlab-ce/issues/17575 https://gitlab.com/gitlab-org/gitlab-ce/issues/17575, https://gitlab.com/gitlab-org/gitlab-ce/issues/14661 https://gitlab.com/gitlab-org/gitlab-ce/issues/14661, https://gitlab.com/gitlab-org/gitlab-ce/issues/15337 https://gitlab.com/gitlab-org/gitlab-ce/issues/15337
- deleted 10y ago
  [deleted]
- rudedogg 10y ago
  I'm running GitLab CE off a NAS to host my projects, and it works really well. Thank you all for making it freely available.
  - sytse 10y ago
    Glad to hear that, thanks for using GitLab! For other people, I think there are Synology packages on https://www.synology.com/en-us/dsm/app_packages/Docker-GitLab https://www.synology.com/en-us/dsm/app_packages/Docker-GitLa...
    - dalanmiller 10y ago
      Unfortunately only for the Intel processor units. I didn't realize this until my ARM-powered device arrived and the package wasn't available.
- Cyph0n 10y ago
  Damn, you are one lucky person! Getting paid to work on OSS is a dream come true. Keep up the awesome work everyone :)
cridenour 10y ago
After GitHub moved to unlimited repositories, I started to question if our small team should stay on GitLab - and this just triple-confirmed that we will. Awesome feature for an already awesome product. Great job!
- sytse 10y ago
  Thank you very much much. I hope your switch goes smoothly.
diggan 10y ago
I'm excited for this, seems like GitLab is moving more into a all-in-one solution, compared to Github that focuses on "social coding", whatever that now means. So to try out this new feature (together with the pipelines), I tried setting up a simple project that uses a docker image to serve a simple html page. However, it seems like it's not possible to build/push from the CI system (unless you setup a self-hosted runner) which kind of leaves this "Container Registry" without value, because I still need to manually build/push my images from one machine...
- sytse 10y ago
  Thanks, our idea is indeed to build an all-in-one solution. For more information see https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope You should be able to build/push from the CI system, see the example GitLab CI configuration file in the blog post. EDIT: For GitLab.com users using shared runners this is waiting on the Runner upgrade that we'll do in the coming days. If you use your own runner that runs 1.2 it should be fine.
  - drewcrawford 10y ago
    Does this work for autoscale runners? Are those privileged by default?
    - sytse 10y ago
      It is about the Runners needing to be on version 1.2. We'll upgrade the .com autoscaling ones in the coming days. If you run your own autoscaling runners you can upgrade yourself.
- tmaczukin 10y ago
  Our shared runners should be updated within a week. Then you will be able to use Container Registry on GitLab.com without self-hosted runner.
- Snappy 10y ago
  Yeah, sorry about that. We'll update the blog post to clarify. We're updating the CI runners this week to support this.
mikewhy 10y ago
This is great! But I'm curious if anyone at Gitlab can comment on what this gives over running the existing docker registry? Can we configure this to use S3 to store the resulting images? Our runner image has docker, we run our tests with docker-compose, if they pass we push them to our existing registry. In fact our .gitlab-ci.yml looks very similar to the example under "elaborate example" in the blog post. Just wondering what we'd be missing out on if we didn't switch to Gitlab Container Registry.
- ayufan 10y ago
  The biggest plus of using integrated registry is that you have integrated authentication and authorization of GitLab that follow your groups and members assigned to your GitLab projects, making it really easy to have private container repositories stored on registry. Second the built-in registry is really easy to configure and maintain. You have to specify the address and provide a certificate to start using it. You also use the same backups mechanism as you use for your GitLab installation. In the future we may make it possible to use external storage for container images, like S3. This is something that is already supported by docker/distribution.
  - Snappy 10y ago
    It really comes down to cost and convenience. We don't charge anything additional to run the container registry (including unlimited private projects for personal or business use), and it's already installed with GitLab. Having said that, we do love deep integration, so we'll continue to improve it going forward. If you have any ideas for improvements, please do create an issue!
  - fapjacks 10y ago
    I am super stoked to see this and will be using the crap out of it and pointing others to it (the registry is kind of a pain to get going)! It looks like this is just the v2 registry (from Distribution) integrated into Gitlab, so I'm wondering what's stopping me from backing this registry with S3? Is it just not supported by the Gitlab config yaml? I back my private registry with S3 and it's just a couple of config options to enable it. Or am I misunderstanding some fundamental concept here? Thanks for the awesome work!
netcraft 10y ago
am I correct that this is only for on-prem deployments, that they aren't going to be offering a public container registry a la docker hub or quay?
- ayufan 10y ago
  The Container Registry is available on our free GitLab.com.
- tmaczukin 10y ago
  You can enable Container Registry for your projects on GitLab.com :) And in a few days our shared runners should be updated to support the full docker workflow with the Container Registry.
  - netcraft 10y ago
    thats really amazing - are there size limits?
    - sytse 10y ago
      Our soft limit is 10GB per project for GitLab.com https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/
SEJeff 10y ago
This might sound like a silly question, but does this require gitlab, or can it work standalone?
- sytse 10y ago
  You install it by installing the GitLab Omnibus package. But you push and pull to it from other application too, no need to use GitLab.
Tiksi 10y ago
It seems like every time I set up some supporting infrastructure it ends up rolled into the next gitlab release a week later, not that I'm complaining (much). If you haven't checked out gitlab in a while, you definitely should. It's been moving fast and come a long way lately. Thank you Gitlab team for making an open source, self hosted platform and all the recent improvements you've made.
- sytse 10y ago
  Thanks for your kind words. May I ask what supporting infrastructure you'll set in 3 weeks from now? We'll have to add it to the schedule for 8.9
  - Tiksi 10y ago
    Well since you asked, I'm working on a system that writes perfect bug-free code for me, but if you can implement that I'll save myself the effort. But really, the next thing on the roadmap is to get tighter integration between our CFM (saltstack/salt-api) and gitlab. Tie it into deploys, auto-open issues on failed states, etc., though that's gonna be more on the salt side than the gitlab side and likely wouldn't make sense for you guys to implement anyways. Im sure I'll end up setting up whatever does make it into 8.9 a week before it's released though.
    - sytse 10y ago
      It would be nice to upload Salt modules directly from GitLab. Since you can deploy from GitLab too, auto-opening issues for failed builds makes sense. I opened an issue on https://gitlab.com/gitlab-org/gitlab-ce/issues/17771 https://gitlab.com/gitlab-org/gitlab-ce/issues/17771 I predict you'll be setting up different environments a week before 8.9 since that is what we'll ship.
allan_s 10y ago
In the same idea, has someone already worked integration with a debian repository (with aptly or similar) and has some linked to share on how to do it the smartway? We're thinking about using FPM to create the debian package Package which is the retrieve as the artifacts of the gitlab-ci build stage And then to have a separate service that will receive a webhook at the end of the (successful) build, to retrieve the artifacts and update a repository using aptly. Does it seems the right way or is there some much simpler solution ?
- mikepurvis 10y ago
  Aptly is a piece of cake compared to reprepro, because of the REST API. I just run it on a separate box, and make curl invocations from Jenkins jobs to post debs to it at the end of the build. Depending what it is you're building, using the proper debian tooling (dpkg-buildpackage, etc) is not that much harder than FPM, and cooperating with the system gives you a lot of goodies for free (sourcedebs, cowbuilder, etc).
- tostaki 10y ago
  At my work, we have a setup close to this. On a successful build of jenkins (after build action), a deb is generated with FPM (awesome piece of software btw) and uploaded to an s3 bucket. Then on another machine, a cron that run every minutes sync the s3 bucket to a local aptly repository and publish it to another s3 bucket which is the real debian repository. This works well but the s3+cron part is probably not the smartest way and publication can take some time (like 5-10min).
  - voltagex_ 10y ago
    I know it probably doesn't matter too much for internal use, but what does Lintian say about your packages?
    - tostaki 10y ago
      Many bad things! I didn't check until now but it's a bunch of "non-standard-dir-perm" and "dir-or-file-in-var-www" and things like "maintainer-name-missing". I think it's possible to build correct debian package with FPM but for our use, we just want to build easily native deb package.
avitzurel 10y ago
Gitlab is what Github was 3 years ago. They are on a roll, rolling out features left and right and seem to nail the need for every engineer. Kudos to the team! Keep rocking!
- sytse 10y ago
  Thank you, we're very determined to keep shipping. Please let us know if there is something you can use that we're not doing yet.
yoavm 10y ago
Up until recently I never even considered using CI in my projects because I just didn't have the time. The way GitLab are implementing all these tools makes it not only easy to use, but fun.
- sytse 10y ago
  Glad to hear that! This was our intention. CI and CD is something everyone knows they should do but it isn't always done. By making it easier to set up we try to get more people to do it and feel good about themselves.
skylan_q 10y ago
These guys are f*cking killing it. Way to go!
iyn 10y ago
I'm really impressed by the hard work of GitLab team, keep it up! If anybody from GitLab is reading: any plans for rkt support?
- Snappy 10y ago
  Thanks! No current plans for rkt, but feel free to create an issue to discuss it.
  - hackbinary 10y ago
    For those who don't know what rkt is, I am presuming that it is the App container runtime: https://coreos.com/rkt/ https://coreos.com/rkt/ https://github.com/coreos/rkt https://github.com/coreos/rkt
  - flexd 10y ago
    I am also interested in rkt support, so I created an issue like you suggested. https://gitlab.com/gitlab-org/gitlab-ce/issues/17784 https://gitlab.com/gitlab-org/gitlab-ce/issues/17784
sotojuan 10y ago
Other good news for GitLab: Zach Holman just joined them as an advisor! https://mobile.twitter.com/holman/status/734842346278244352 https://mobile.twitter.com/holman/status/734842346278244352
- sytse 10y ago
  HN discussion of that tweet in https://news.ycombinator.com/item?id=11756674 https://news.ycombinator.com/item?id=11756674 BTW that post and this post are 1 and 2 on HN right now
thebouv 10y ago
I've tried several times to figure out how to get Docker working in a situation like mine. And we've been considering GitLab as well. So this is likely a good time to experiment. Doing all the research on how to integrate Docker into my particular situation has been daunting. I really need to track down some online courses or something. The articles just aren't cutting it. Or need to find a mentor just to ask stupid questions to.
Tomdarkness 10y ago
Looks great. One thing that does not appear to be clear though is if you build multiple docker images from the same project. Our deployment workflow at the moment builds two docker images, one for the web app and another for the background services. Both share the same code. It would appear you can only have one docker image per project?
- hackerboos 10y ago
  AFAIK you can just have 2 stages to build each image and push both under different tags.
  - sytse 10y ago
    You can do this but currently you can have only one image per project. We did this to keep it simple. You can use a dummy project to work around it. Or consider making web app and the background services separate projects.
btashton 10y ago
When would we expect to see this on githost.io?
- dblessing 10y ago
  We are investigating what it will take to enable this on GitHost.io. At first glance, it doesn't seem to be too difficult. I created https://gitlab.com/gitlab-com/githost/issues/12 https://gitlab.com/gitlab-com/githost/issues/12 to track this feature request.
alfg 10y ago
So awesome! I've been invested into the Docker ecosystem lately and one of the next things I've wanted to setup is a decent CI workflow. I wish Github would also ship more features at the pace Gitlab is. The only issue I've had with Gitlab are the response times on their UI. Hopefully they sort that out soon.
- jobvandervoort 10y ago
  I suppose you are using GitLab.com. We're working on improving the speed [0]. If you are willing to run your own instance, it should be fast. [0]: https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42
znpy 10y ago
It's happening: GitLab has basically filled the feature gap with GitHub and it is surpassing it.
- voltagex_ 10y ago
  Once the performance gap closes it'll be even more exciting. I just worry about 10, 15, 20 years in the future when ArchiveTeam has to back up GitHub and GitLab and whatever else... there's so much data!
  - znpy 10y ago
    There will also be bigger storage :)
nhumrich 10y ago
Can I use gitlab container registry with gitlab.com? Can I use private images in said registry with public gitlab.com ci builders? I haven't found a way to use private containers with gitlab.com ci yet without spinning up a worker for every project. Maybe a way to register a "team wide" builder?
- ayufan 10y ago
  Currently not. The limitations can be found here: http://docs.gitlab.com/ce/container_registry/README.html#limitations http://docs.gitlab.com/ce/container_registry/README.html#lim.... We plan to improve that in one of upcoming releases.
pritambarhate 10y ago
These days it seems that Docker is everywhere. I am new to docker and I seem to find it as one more additional complicated system that the developer now needs to learn in order to deploy his or her application. How useful do you find docker for application which can be deployed on Heroku or Beanstalk? I can understand using docker for a Language ecosystem which is not supported on Public PaaS. Or for people for whom public PaaS is not an option. I would like to know about the experience of using Docker in day to day development from people who have used Docker in team environments. How was your experience of converting the team to use Docker instead of their regular development/deployment? For example, at our company, For LAMP or MEAN or Java Stacks, we have a defined a procedure of setting up the dev machines to include all these tools and developers know how to manage these on their own machine. Once the code is pushed to Jenkins, there are deploy scripts written by tech leads which take care of deployment to various servers or to Heroku. In your Docker driven development process, did everybody started using docker on their development machine too? Or everybody just kept using their local setup, and only one/two people handled the task of creating final docker images? Or do you just use you CI server to handle the docker image creation and deployment from that point onwards?
- trey-jones 10y ago
  I am also pretty new to docker and it took a few days to get my head into it, but I am using it mainly as a contained dev environment, similar to the way we use vagrant. I am finding that docker is much better suited to complex environments, and a lot easier to update. Contrary to your fears of everyone having to learn docker to develop, I see it as a tool that allows every developer on a team to be brought into new technology without having to learn all about a new toolchain. We are using docker-compose for this. Everyone has to install docker, and have some cursory knowledge of docker-compose commands, but that's it. As an example, I recently shoehorned an angular2 front end into an existing project. Without docker, this means every developer needs node and all the dependencies before they begin to work. With docker-compose, the next time they start up the environment, the npm container installs all of their dependencies, and the typescript compiler container listens and compiles all changes to the webroot. The other developers don't even need to know what node is, or that it's being used! Docker is a very powerful tool with a lot of untapped potential I'm sure. I've no experience with docker in production, however.
educar 10y ago
I wish Gitlab had an easy clean way to import GitHub. The current method involves setting up oauth information in the config file and restarting gitlab. Not nice :/ I fail to see why they cannot just work with GitHub API tokens for import?

449 points by martgnz 10y ago

Interesting move. Seems Gitlab are moving fairly fast (compared to competition) and going for that all in one ecosystem (If you want it) from SCM to deployment with the range of products they've introduced.

ayufan 10y ago
We are thinking big. The integrated Container Registry is part of our plan. We will soon have an integrated deployments with easy to access environments. We also plan to introduce manual actions on pipelines allowing you to execute arbitary things, ex. promote to production, but also merge it back to the master. https://gitlab.com/gitlab-org/gitlab-ce/issues/17009 https://gitlab.com/gitlab-org/gitlab-ce/issues/17009 https://gitlab.com/gitlab-org/gitlab-ce/issues/17010 https://gitlab.com/gitlab-org/gitlab-ce/issues/17010

lukebennett 10y ago

Fantastic, Gitlab are absolutely nailing it at the moment. Don't think there's any other hosted service offering so many CI/CD features for free under one roof. It feels like what Github did for SCM, Gitlab are doing for CI.

sytse 10y ago
Thanks Luke! We'll try to keep this going. We're working on deployment environments for our next release so you can see what is deployed in each environment. After that we can do deployments that need to be confirm manually.
- jstsch 10y ago
  Wow, that's great news. Exactly what we are looking for. I was investigating to use GitLab CI to build, and then only deploy commits with a certain tag, but a dedicated workflow for deployments is much more convenient and less error-prone.
  - sytse 10y ago
    Glad to hear that. By the way, the 'only deploy tags' strategy is already possible today if you want to do it that way.
FireBeyond 10y ago
I agree, this is awesome. Their post yesterday hinted at something, and I honestly didn't think it would be this exciting. I can't wait to use it.
- sytse 10y ago
  Thanks, glad you like it. BTW I wonder how many people understood our hint yesterday: "We almost can't _contain_ our excitement about how our announcement on Monday will _register_ with you!".
  - lukebennett 10y ago
    Heh, I didn't read the hint until after the registry announcement, but saw what you did and appreciated it with the benefit of hindsight!

nikolay 10y ago

At this pace of innovation, GitHub will soon be a part of the history! GitHub has done a tremendous job with forking and pull requests, but, at least recently, they've acted disorientedly! I hope they get back into shape!

r3bl 10y ago
I really don't know what to hope for. All that I do now that I really enjoy watching what looks like a full on feature battle between GitLab and GitHub going on at this moment. As a guy who uses both (GitLab for my job, GitHub personally), I feel like I'm getting the best of both worlds. Although, to be perfectly honest, it feels to me like, at this point of the "feature battle", GitLab started embracing and actually improving every single thing I liked about GitHub to the point where I'm questioning my stay on GitHub for personal projects.
- andromeduck 10y ago
  now if only they could get gitlab.com page loads consistently under 1 second... x_x
  - sytse 10y ago
    Yes, we should fix the slow page loads on GitLab.com. We're working on it in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42 I'm sorry for the current slowness.
  - recuter 10y ago
    This is my first week at Gitlab. I've joined along with a few other people (one of whom has a great big bushy beard) to specifically make you happy. There are interesting challenges that currently make this none trivial but expect things to improve greatly in the near future.
  - nikolay 10y ago
    Yup! It supposedly is written in a much more efficient language, but it severely slower than GitHub and Bitbucket.

davexunit 10y ago

Awesome, a new place to host your unpatched, opaque disk images!

moondev 10y ago
https://imagelayers.io https://imagelayers.io
sytse 10y ago
I think the patching of Docker container images is a big problem. We try to provide a completely automated flow in GitLab using CI, CD, and the container registry. I would love to have a big button that says 'update all my containers'. I've made an issue https://gitlab.com/gitlab-org/gitlab-ee/issues/592 https://gitlab.com/gitlab-org/gitlab-ee/issues/592
- davexunit 10y ago
  The problem is that Docker, and more generally using stacks of binary disk images, is fundamentally flawed with respect to security and reproducibility. It's nontrivial to inspect these images for vulnerabilities because there is nothing that specifies the precise set of software that is in that image. Some stuff is compiled from source, some stuff is installed via one or more package managers, each of which may bundle additional software that one may not know about if they didn't inspect each piece of software carefully. Furthermore, one cannot even verify the image reasonably because the results are different depending on when it was built. In short, container images as popularized by Docker are insecure by design.
  - justinsaccount 10y ago
    Can I play too? The problem is that unix, and more generally any operating system, is fundamentally flawed with respect to security and reproducibility. It's nontrivial to inspect these installations for vulnerabilities because there is nothing that specifies the precise set of software that is in that installation. Some stuff is compiled from source, some stuff is installed via one or more package managers, each of which may bundle additional software that one may not know about if they didn't inspect each piece of software carefully. Furthermore, one cannot even verify the installation reasonably because the results are different depending on when it was installed. In short, operating systems are insecure by design.

andrewmunsell 10y ago

Everyone at GitLab has been doing an amazing job shipping some really cool features. I'm really looking forward to trying out the new container registry and move away from my hack-y solution that I use right now to build Docker images on my own VM, and move back to the shared runners :)

sytse 10y ago
Thanks Andrew, I hope your move goes smoothly. We want to allow everyone to go frictionless from idea to production. We're extending GitLab so this can be done simply without having to script things together yourself.

connorshea 10y ago

Kind of unrelated, but I'm super happy to be working at GitLab. Nearly everything we do is out in the open, and most features are available in CE, which is fully open source (https://gitlab.com/gitlab-org/gitlab-ce https://gitlab.com/gitlab-org/gitlab-ce). I've wanted great, open source tools that don't look like dung for a long long time, and GitLab is definitely reaching that goal. Can't help but gush about the product we're building. :D Here are some of my favorite upcoming features: https://gitlab.com/gitlab-org/gitlab-ce/issues/17575 https://gitlab.com/gitlab-org/gitlab-ce/issues/17575, https://gitlab.com/gitlab-org/gitlab-ce/issues/14661 https://gitlab.com/gitlab-org/gitlab-ce/issues/14661, https://gitlab.com/gitlab-org/gitlab-ce/issues/15337 https://gitlab.com/gitlab-org/gitlab-ce/issues/15337

deleted 10y ago
[deleted]
rudedogg 10y ago
I'm running GitLab CE off a NAS to host my projects, and it works really well. Thank you all for making it freely available.
- sytse 10y ago
  Glad to hear that, thanks for using GitLab! For other people, I think there are Synology packages on https://www.synology.com/en-us/dsm/app_packages/Docker-GitLab https://www.synology.com/en-us/dsm/app_packages/Docker-GitLa...
  - dalanmiller 10y ago
    Unfortunately only for the Intel processor units. I didn't realize this until my ARM-powered device arrived and the package wasn't available.
Cyph0n 10y ago
Damn, you are one lucky person! Getting paid to work on OSS is a dream come true. Keep up the awesome work everyone :)

cridenour 10y ago

After GitHub moved to unlimited repositories, I started to question if our small team should stay on GitLab - and this just triple-confirmed that we will. Awesome feature for an already awesome product. Great job!

sytse 10y ago
Thank you very much much. I hope your switch goes smoothly.

diggan 10y ago

I'm excited for this, seems like GitLab is moving more into a all-in-one solution, compared to Github that focuses on "social coding", whatever that now means. So to try out this new feature (together with the pipelines), I tried setting up a simple project that uses a docker image to serve a simple html page. However, it seems like it's not possible to build/push from the CI system (unless you setup a self-hosted runner) which kind of leaves this "Container Registry" without value, because I still need to manually build/push my images from one machine...

sytse 10y ago
Thanks, our idea is indeed to build an all-in-one solution. For more information see https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope You should be able to build/push from the CI system, see the example GitLab CI configuration file in the blog post. EDIT: For GitLab.com users using shared runners this is waiting on the Runner upgrade that we'll do in the coming days. If you use your own runner that runs 1.2 it should be fine.
- drewcrawford 10y ago
  Does this work for autoscale runners? Are those privileged by default?
  - sytse 10y ago
    It is about the Runners needing to be on version 1.2. We'll upgrade the .com autoscaling ones in the coming days. If you run your own autoscaling runners you can upgrade yourself.
tmaczukin 10y ago
Our shared runners should be updated within a week. Then you will be able to use Container Registry on GitLab.com without self-hosted runner.
Snappy 10y ago
Yeah, sorry about that. We'll update the blog post to clarify. We're updating the CI runners this week to support this.

mikewhy 10y ago

This is great! But I'm curious if anyone at Gitlab can comment on what this gives over running the existing docker registry? Can we configure this to use S3 to store the resulting images? Our runner image has docker, we run our tests with docker-compose, if they pass we push them to our existing registry. In fact our .gitlab-ci.yml looks very similar to the example under "elaborate example" in the blog post. Just wondering what we'd be missing out on if we didn't switch to Gitlab Container Registry.

ayufan 10y ago
The biggest plus of using integrated registry is that you have integrated authentication and authorization of GitLab that follow your groups and members assigned to your GitLab projects, making it really easy to have private container repositories stored on registry. Second the built-in registry is really easy to configure and maintain. You have to specify the address and provide a certificate to start using it. You also use the same backups mechanism as you use for your GitLab installation. In the future we may make it possible to use external storage for container images, like S3. This is something that is already supported by docker/distribution.
- Snappy 10y ago
  It really comes down to cost and convenience. We don't charge anything additional to run the container registry (including unlimited private projects for personal or business use), and it's already installed with GitLab. Having said that, we do love deep integration, so we'll continue to improve it going forward. If you have any ideas for improvements, please do create an issue!
- fapjacks 10y ago
  I am super stoked to see this and will be using the crap out of it and pointing others to it (the registry is kind of a pain to get going)! It looks like this is just the v2 registry (from Distribution) integrated into Gitlab, so I'm wondering what's stopping me from backing this registry with S3? Is it just not supported by the Gitlab config yaml? I back my private registry with S3 and it's just a couple of config options to enable it. Or am I misunderstanding some fundamental concept here? Thanks for the awesome work!

netcraft 10y ago

am I correct that this is only for on-prem deployments, that they aren't going to be offering a public container registry a la docker hub or quay?

ayufan 10y ago
The Container Registry is available on our free GitLab.com.
tmaczukin 10y ago
You can enable Container Registry for your projects on GitLab.com :) And in a few days our shared runners should be updated to support the full docker workflow with the Container Registry.
- netcraft 10y ago
  thats really amazing - are there size limits?
  - sytse 10y ago
    Our soft limit is 10GB per project for GitLab.com https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/

SEJeff 10y ago

This might sound like a silly question, but does this require gitlab, or can it work standalone?

sytse 10y ago
You install it by installing the GitLab Omnibus package. But you push and pull to it from other application too, no need to use GitLab.

Tiksi 10y ago

It seems like every time I set up some supporting infrastructure it ends up rolled into the next gitlab release a week later, not that I'm complaining (much). If you haven't checked out gitlab in a while, you definitely should. It's been moving fast and come a long way lately. Thank you Gitlab team for making an open source, self hosted platform and all the recent improvements you've made.

sytse 10y ago
Thanks for your kind words. May I ask what supporting infrastructure you'll set in 3 weeks from now? We'll have to add it to the schedule for 8.9
- Tiksi 10y ago
  Well since you asked, I'm working on a system that writes perfect bug-free code for me, but if you can implement that I'll save myself the effort. But really, the next thing on the roadmap is to get tighter integration between our CFM (saltstack/salt-api) and gitlab. Tie it into deploys, auto-open issues on failed states, etc., though that's gonna be more on the salt side than the gitlab side and likely wouldn't make sense for you guys to implement anyways. Im sure I'll end up setting up whatever does make it into 8.9 a week before it's released though.
  - sytse 10y ago
    It would be nice to upload Salt modules directly from GitLab. Since you can deploy from GitLab too, auto-opening issues for failed builds makes sense. I opened an issue on https://gitlab.com/gitlab-org/gitlab-ce/issues/17771 https://gitlab.com/gitlab-org/gitlab-ce/issues/17771 I predict you'll be setting up different environments a week before 8.9 since that is what we'll ship.

allan_s 10y ago

In the same idea, has someone already worked integration with a debian repository (with aptly or similar) and has some linked to share on how to do it the smartway? We're thinking about using FPM to create the debian package Package which is the retrieve as the artifacts of the gitlab-ci build stage And then to have a separate service that will receive a webhook at the end of the (successful) build, to retrieve the artifacts and update a repository using aptly. Does it seems the right way or is there some much simpler solution ?

mikepurvis 10y ago
Aptly is a piece of cake compared to reprepro, because of the REST API. I just run it on a separate box, and make curl invocations from Jenkins jobs to post debs to it at the end of the build. Depending what it is you're building, using the proper debian tooling (dpkg-buildpackage, etc) is not that much harder than FPM, and cooperating with the system gives you a lot of goodies for free (sourcedebs, cowbuilder, etc).
tostaki 10y ago
At my work, we have a setup close to this. On a successful build of jenkins (after build action), a deb is generated with FPM (awesome piece of software btw) and uploaded to an s3 bucket. Then on another machine, a cron that run every minutes sync the s3 bucket to a local aptly repository and publish it to another s3 bucket which is the real debian repository. This works well but the s3+cron part is probably not the smartest way and publication can take some time (like 5-10min).
- voltagex_ 10y ago
  I know it probably doesn't matter too much for internal use, but what does Lintian say about your packages?
  - tostaki 10y ago
    Many bad things! I didn't check until now but it's a bunch of "non-standard-dir-perm" and "dir-or-file-in-var-www" and things like "maintainer-name-missing". I think it's possible to build correct debian package with FPM but for our use, we just want to build easily native deb package.

avitzurel 10y ago

Gitlab is what Github was 3 years ago. They are on a roll, rolling out features left and right and seem to nail the need for every engineer. Kudos to the team! Keep rocking!

sytse 10y ago
Thank you, we're very determined to keep shipping. Please let us know if there is something you can use that we're not doing yet.

yoavm 10y ago

Up until recently I never even considered using CI in my projects because I just didn't have the time. The way GitLab are implementing all these tools makes it not only easy to use, but fun.

sytse 10y ago
Glad to hear that! This was our intention. CI and CD is something everyone knows they should do but it isn't always done. By making it easier to set up we try to get more people to do it and feel good about themselves.

skylan_q 10y ago

These guys are f*cking killing it. Way to go!

iyn 10y ago

I'm really impressed by the hard work of GitLab team, keep it up! If anybody from GitLab is reading: any plans for rkt support?

Snappy 10y ago
Thanks! No current plans for rkt, but feel free to create an issue to discuss it.
- hackbinary 10y ago
  For those who don't know what rkt is, I am presuming that it is the App container runtime: https://coreos.com/rkt/ https://coreos.com/rkt/ https://github.com/coreos/rkt https://github.com/coreos/rkt
- flexd 10y ago
  I am also interested in rkt support, so I created an issue like you suggested. https://gitlab.com/gitlab-org/gitlab-ce/issues/17784 https://gitlab.com/gitlab-org/gitlab-ce/issues/17784

sotojuan 10y ago

Other good news for GitLab: Zach Holman just joined them as an advisor! https://mobile.twitter.com/holman/status/734842346278244352 https://mobile.twitter.com/holman/status/734842346278244352

sytse 10y ago
HN discussion of that tweet in https://news.ycombinator.com/item?id=11756674 https://news.ycombinator.com/item?id=11756674 BTW that post and this post are 1 and 2 on HN right now

thebouv 10y ago

I've tried several times to figure out how to get Docker working in a situation like mine. And we've been considering GitLab as well. So this is likely a good time to experiment. Doing all the research on how to integrate Docker into my particular situation has been daunting. I really need to track down some online courses or something. The articles just aren't cutting it. Or need to find a mentor just to ask stupid questions to.

Tomdarkness 10y ago

Looks great. One thing that does not appear to be clear though is if you build multiple docker images from the same project. Our deployment workflow at the moment builds two docker images, one for the web app and another for the background services. Both share the same code. It would appear you can only have one docker image per project?

hackerboos 10y ago
AFAIK you can just have 2 stages to build each image and push both under different tags.
- sytse 10y ago
  You can do this but currently you can have only one image per project. We did this to keep it simple. You can use a dummy project to work around it. Or consider making web app and the background services separate projects.

btashton 10y ago

When would we expect to see this on githost.io?

dblessing 10y ago
We are investigating what it will take to enable this on GitHost.io. At first glance, it doesn't seem to be too difficult. I created https://gitlab.com/gitlab-com/githost/issues/12 https://gitlab.com/gitlab-com/githost/issues/12 to track this feature request.

alfg 10y ago

So awesome! I've been invested into the Docker ecosystem lately and one of the next things I've wanted to setup is a decent CI workflow. I wish Github would also ship more features at the pace Gitlab is. The only issue I've had with Gitlab are the response times on their UI. Hopefully they sort that out soon.

jobvandervoort 10y ago
I suppose you are using GitLab.com. We're working on improving the speed [0]. If you are willing to run your own instance, it should be fast. [0]: https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42

znpy 10y ago

It's happening: GitLab has basically filled the feature gap with GitHub and it is surpassing it.

voltagex_ 10y ago
Once the performance gap closes it'll be even more exciting. I just worry about 10, 15, 20 years in the future when ArchiveTeam has to back up GitHub and GitLab and whatever else... there's so much data!
- znpy 10y ago
  There will also be bigger storage :)

nhumrich 10y ago

Can I use gitlab container registry with gitlab.com? Can I use private images in said registry with public gitlab.com ci builders? I haven't found a way to use private containers with gitlab.com ci yet without spinning up a worker for every project. Maybe a way to register a "team wide" builder?

ayufan 10y ago
Currently not. The limitations can be found here: http://docs.gitlab.com/ce/container_registry/README.html#limitations http://docs.gitlab.com/ce/container_registry/README.html#lim.... We plan to improve that in one of upcoming releases.

pritambarhate 10y ago

These days it seems that Docker is everywhere. I am new to docker and I seem to find it as one more additional complicated system that the developer now needs to learn in order to deploy his or her application. How useful do you find docker for application which can be deployed on Heroku or Beanstalk? I can understand using docker for a Language ecosystem which is not supported on Public PaaS. Or for people for whom public PaaS is not an option. I would like to know about the experience of using Docker in day to day development from people who have used Docker in team environments. How was your experience of converting the team to use Docker instead of their regular development/deployment? For example, at our company, For LAMP or MEAN or Java Stacks, we have a defined a procedure of setting up the dev machines to include all these tools and developers know how to manage these on their own machine. Once the code is pushed to Jenkins, there are deploy scripts written by tech leads which take care of deployment to various servers or to Heroku. In your Docker driven development process, did everybody started using docker on their development machine too? Or everybody just kept using their local setup, and only one/two people handled the task of creating final docker images? Or do you just use you CI server to handle the docker image creation and deployment from that point onwards?

trey-jones 10y ago
I am also pretty new to docker and it took a few days to get my head into it, but I am using it mainly as a contained dev environment, similar to the way we use vagrant. I am finding that docker is much better suited to complex environments, and a lot easier to update. Contrary to your fears of everyone having to learn docker to develop, I see it as a tool that allows every developer on a team to be brought into new technology without having to learn all about a new toolchain. We are using docker-compose for this. Everyone has to install docker, and have some cursory knowledge of docker-compose commands, but that's it. As an example, I recently shoehorned an angular2 front end into an existing project. Without docker, this means every developer needs node and all the dependencies before they begin to work. With docker-compose, the next time they start up the environment, the npm container installs all of their dependencies, and the typescript compiler container listens and compiles all changes to the webroot. The other developers don't even need to know what node is, or that it's being used! Docker is a very powerful tool with a lot of untapped potential I'm sure. I've no experience with docker in production, however.

educar 10y ago

I wish Gitlab had an easy clean way to import GitHub. The current method involves setting up oauth information in the config file and restarting gitlab. Not nice :/ I fail to see why they cannot just work with GitHub API tokens for import?