This issue is somewhat urgent:
I’m attempting to upgraded my containerized gitlab-ce to latest release. Using guiding instructions here.
Background: I’ve had a dockerized version of gitlab-ce (14.73) with Mattermost running and needed to upgrade.
I’m on Ubuntu 20.04. Both gitlab and mattermost were running fine before upgrade. We use NGINX to route to our
gitlab.site.com (actual name changed to protect innocent)
but have encountered the following error:
root@omeda:~/ $ sudo docker run --detach --hostname gitlab.site.com --publish 443:443 --publish 80:80 --publish 22
:22 --name gitlab --restart always --volume $GITLAB_HOME/config:/etc/gitlab --volume $GITLAB_HOME/logs:/var/log/gitlab --volume $GITLAB_HOME/data:/var/opt/gitlab --sh
m-size 256m gitlab/gitlab-ce:latest
Which generated the following error:
565a03da8bc35b30 [snip…snip] dd0f0989b30f05b8012bc8b0cb40
docker: Error response from daemon: driver failed programming external connectivity on endpoint gitlab (2e5732216ff9eba5058 [snip…snip] 6fb50d0e117da7a5cce6f90b525
c6): Error starting userland proxy: listen tcp4 0.0.0.0:443: bind: address already in use.
I assumed naively, that previous install used typical port mappings and didn’t make note of what was set before. I don’t know what to change to fix. Unfortunately, the IT person who installed this no longer here.
Thanks for your prompt response…
Problem with upgrade solved. I misread the gitlab documentation and was led to believe I didn’t need to do incremental updates. My mistake.
@timbopoise, happy to see that you worked it out!
I misread the gitlab documentation and was led to believe I didn’t need to do incremental updates
Could you please share a link? I’d like to see if I can improve on it to make it clearer. If you have a wording suggestion, I’m all ears.
Thank you
thiagocst,
I’m happy to followup regarding my gitlab upgrade attempt.
As I said I misread, despite plenty of warning, the task at hand and thought I had seen a statement that gave me rationale to continue with straight upgrade from 14.7 to latest–probably was wishful thinking.
I tried to go back and find the areas that might have given me a good excuse but apparently I was reaching.
However, during my review of the pages that I read (I’m embarrassed to say that I read many times) I recall an area of the documentation and terminology that repeatedly confused me:
This section
- Linux packages (Omnibus GitLab)
versus
- docker.
I feel that I have both in my case. Or at least it was unclear exactly what an Omnibus install was, but I kept seeing details that lead me to believe it applied to me. And yet we also clearly using docker containerization.
To be more constructive in my feedback I’d say that the documentation assumes that the reader was involved in the installation, as opposed to someone who has come along later to perform backups and upgrade, like me.
I also think I would have benefited from a clearer understanding (from someone who did not install original instance) of the relationship between the operation of gitlab vs mattermost. I know gitlab team did not develop Mattermost, but there’s good reason that they have been combined and one does not see mattermost running anywhere, per se.
I feel awkward saying anything because I found gitlab.s online documentation to be very good.
Thank you very much.
1 Like
No, omnibus is the packaged version which you normally install on a standard VM using the repositories be it for Debian/Ubuntu, or RPM-based distros. Docker is something else entirely so doesn’t quite refer to Omnibus as such. In terms of documentation, it’s very sparse when it comes to docker and doesn’t explain a lot for the appropriate commands to run in docker. The docs do need some work to address situations such as upgrades, backups, restore, etc when people are using docker as it’s rather limited in terms of “docker-specific” commands to be ran to do these things. At least my opinion anyway.
Generally though, the docs are good, especially for omnibus or source installations.
1 Like
Thanks for the kind words, @timbopoise. If you think of any specific things to improve, I’m happy to put an MR in or to guide you through the process of contributing.
Taking a clue from @iwalker’s comment, I searched for open issues related to docker documentation. Indeed there are quite a few, including some 5+ years old :-/