provide automatically build dockerimage #3

Closed
opened 1 year ago by lobi · 4 comments
lobi commented 1 year ago

It would be nice if there is an automatically build official dockerimage available.
This will simplyfy the documentation for "getting started" and will be a huge performance
improvement on deployment.
Because codeberg.org does not have a docker registry I have created a project on gitlab.com lobi/timelimit-server to show an example on how we can do this.
The downside of this project is, that it only builds automatically on a dayly basis, not on each commit on master.
I would suggest to integrate a .gitlab-ci.yml in to this project and create a project on gitlab.com that stays in sync with this one. Doing this the project can remain a project on codeberg.org but profit from the benifit that open source projects get unlimited build time on gitlab.com.

It would be nice if there is an automatically build official dockerimage available. This will simplyfy the documentation for "getting started" and will be a huge performance improvement on deployment. Because codeberg.org does not have a docker registry I have created a project on gitlab.com [lobi/timelimit-server](https://gitlab.com/lobi/timelimit-server) to show an example on how we can do this. The downside of this project is, that it only builds automatically on a dayly basis, not on each commit on master. I would suggest to integrate a `.gitlab-ci.yml` in to this project and create a project on gitlab.com that stays in sync with this one. Doing this the project can remain a project on codeberg.org but profit from the benifit that open source projects get unlimited build time on gitlab.com.
Owner

Well, this project was hosted at GitLab in the past and it had a gitlab ci config - see https://codeberg.org/timelimit/timelimit-server/commit/41d6c5e76510954741459f3a1b4520a9aa52eac5.

Because I try to avoid US services, I don't want to use GitLab for offical images. But I think it's not impossible to self host such a thing.

The main problem with this is that I don't like prebuilt binaries - as far as I know it's difficult for a user to verify that a docker image contains the unmodified software. With the source code, there is git and it's visible what has changed.

Well, this project was hosted at GitLab in the past and it had a gitlab ci config - see <https://codeberg.org/timelimit/timelimit-server/commit/41d6c5e76510954741459f3a1b4520a9aa52eac5>. Because I try to avoid US services, I don't want to use GitLab for offical images. But I think it's not impossible to self host such a thing. The main problem with this is that I don't like prebuilt binaries - as far as I know it's difficult for a user to verify that a docker image contains the unmodified software. With the source code, there is git and it's visible what has changed.
lobi commented 1 year ago
Poster

I understand your hint to the trust problem. But providing an official binary is in no conflic with having the git source for users who do not trust enouth and want to build it on thair own.
It is not very difficult to compare self build dockerimage is the same as one build by someone else as long as the underlying layers are the same.
But you are totaly right if the underlying layers change for some reason you have to veryfy again even if there is no change in the source repo.
Saying this I would argue it is the responsibility of the user to make the decision which way to go. It depents on the level of security and trust and on budget.

I also basicly understand that you do not want to relay too much on US services. But as it is possible to self host the same thing there is no big lock-in effect to pay.

If you think it is worth to host an own gitlabinstance or a build server and a docker registry like harbor this is also great. I would suport you on this as good as I can anyway.

One question for in the meantime: I see there is now an entry in releases. As much I can see this is not related to any git tag, right? If I want to improve my pipeline to provide image tags for speciic releases should I rely on the date based release naming or the version number? Ok two questions: And if I should still use theverion number e.g. 3.2.0 what would you say is the easiestway to get it from the repo (what about using tags)?

Ah and I totaly forgot to say realy great project, thanks for all the work! I have written about it in my german blog https://hub.xdit.de/channel/lobi-blog.
Just had lost my contact lenses and so was unable to do anything on computers the last weeks.

I understand your hint to the trust problem. But providing an official binary is in no conflic with having the git source for users who do not trust enouth and want to build it on thair own. It is not very difficult to compare self build dockerimage is the same as one build by someone else as long as the underlying layers are the same. But you are totaly right if the underlying layers change for some reason you have to veryfy again even if there is no change in the source repo. Saying this I would argue it is the responsibility of the user to make the decision which way to go. It depents on the level of security and trust and on budget. I also basicly understand that you do not want to relay too much on US services. But as it is possible to self host the same thing there is no big lock-in effect to pay. If you think it is worth to host an own gitlabinstance or a build server and a docker registry like harbor this is also great. I would suport you on this as good as I can anyway. One question for in the meantime: I see there is now an entry in releases. As much I can see this is not related to any git tag, right? If I want to improve my pipeline to provide image tags for speciic releases should I rely on the date based release naming or the version number? Ok two questions: And if I should still use theverion number e.g. 3.2.0 what would you say is the easiestway to get it from the repo (what about using tags)? Ah and I totaly forgot to say realy great project, thanks for all the work! I have written about it in my german blog https://hub.xdit.de/channel/lobi-blog. Just had lost my contact lenses and so was unable to do anything on computers the last weeks.
Owner

The pulling of a docker image seems to be just a series of get and head http requests - https://docs.docker.com/registry/spec/api/#pulling-an-image. I don't want any complex software, instead I would prefer a solution which generates the required file structure which I can serve using a normal webserver. The only problem for now is the creation of this structure.

The images itself are already built at the target system, so they exist already and the only remaining part is to upload them somewhere. This is something I can do manually - there is no GitLab or build server required (which would be too much overhead for this).

The release is connected to the tag 2020-07-07. The 3.2.0 is a reference to a client version. The current plan is that when a commit is deployed at api.timelimit.io and it works, then a release/ tag with the date as name is created which indicates that one should use it.

The pulling of a docker image seems to be just a series of get and head http requests - <https://docs.docker.com/registry/spec/api/#pulling-an-image>. I don't want any complex software, instead I would prefer a solution which generates the required file structure which I can serve using a normal webserver. The only problem for now is the creation of this structure. The images itself are already built at the target system, so they exist already and the only remaining part is to upload them somewhere. This is something I can do manually - there is no GitLab or build server required (which would be too much overhead for this). The release is connected to the tag ``2020-07-07``. The ``3.2.0`` is a reference to a client version. The current plan is that when a commit is deployed at api.timelimit.io and it works, then a release/ tag with the date as name is created which indicates that one should use it.
Owner
There are now prebuild images avaialable => https://codeberg.org/timelimit/timelimit-server/src/branch/master/docs/usage/docker.md#user-content-important Thanks for the idea.
jonas-l closed this issue 1 year ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.