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?
Thanks!
No current plans for rkt, but feel free to create an issue to discuss it.
GitLab Container Registry
51–60 of 121 posts
Re: GitLab Container Registry
#52Gitlab 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!
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.
Re: GitLab Container Registry
#53Earlier quoted context omitted.
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
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 bund…
if you're building go or rust packages, all you need is the output executable alone a lot of the time. :-) The host OS and docker version provide most of the low-level bits.
Re: GitLab Container Registry
#54Earlier quoted context omitted.
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…
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 o…
Glad to hear you're super stoked! I think you're on the money regarding the s3 backup. I think it is making the configuration accessible. I expect you can work around that by doing it yourself.
Re: GitLab Container Registry
#55Other good news for GitLab: Zach Holman just joined them as an advisor!
Re: GitLab Container Registry
#56Earlier quoted context omitted.
Don't you think that gitlab adding container registry support will encourage more people to build their own images, as opposed to trusting "black-box" images from elsewhere? Combining a base image with the deployable artifact is much more efficient than baking amis or other images. You then know exactly what your image contains and nothing more, because you built it yourself. Of course I'm looking at this from the pe…
Any nontrivial image relies on a large number of other images as a base, and just because you built it yourself doesn't mean that you didn't just download and install software with known security vulnerabilities.
Yes, but you will ALWAYS have that issue with software you build yourself. This is primarily why I maintain an in-house yum repository for anything that we use out of our distribution repositories, it takes a little more effort to build RPM's but it's worth it from a maintainability and security aspect (as I type this I'm working on a salt-based package management tool somewhat akin to Katello/Sattelite that I can use to manage upgrades that Puppet doesn't).
Re: GitLab Container Registry
#57Earlier quoted context omitted.
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 bund…
Don't you think that gitlab adding container registry support will encourage more people to build their own images, as opposed to trusting "black-box" images from elsewhere? Combining a base image with the deployable artifact is much more efficient than baking amis or other images. You then know exactly what your image contains and nothing more, because you built it yourself. Of course I'm looking at this from the pe…
I agree that building your own images is the future. We want to make this as easy as possible. I think it is essential for security.
Re: GitLab Container Registry
#58I'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 ru…
Ah, thanks to sytse, Snappy and tmaczukin for the replis. I missed that. My configuration looks like this currently (and I'm guessing I'll hold of for a few days for the shared workers to get updated): image: docker:latest services: - docker:dind stages: - build - deploy build: stage: build script: - docker build -t registry.gitlab.com/victorbjelkholm/deploy-html-test:latest . only: - master deploy: stage: deploy scr…
If you're going to use the shared runners, I don't think that configuration is going to work. The build step will build it locally, and even though you named it to use the registry, it won't actually push to the registry automatically. By breaking up the push to another step, you're actually going to run that deploy stage on a fresh Digital Ocean instance, so your previously-built image will be lost.
That's why the example pushed the image right after the build step.
Having said that, if you're literally using that script, you don't even have tests, so you may as well just put both steps into a single build stage like the simplified example. :)
For now, you'll need the explicit `docker login` as well. We'll work to remove that.
Re: GitLab Container Registry
#59I'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.
Re: GitLab Container Registry
#60Looks 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?