Gitlab-ce mattermost upgrade - restarting new gitlab container bind address already in use

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 (actual name changed to protect innocent)

but have encountered the following error:

root@omeda:~/ $ sudo docker run --detach --hostname --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 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…

@iwalker can you help?

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

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)
  • 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 :-/