I'm currently using Gitlab using Docker. The container is using the latest image for Gitlab, but the admin area shows me a different version. How can I use the latest one ? I don't understand why Gitlab shows me a different version of what I'm using. I tried gitlab-ctl upgrade command, with no effect.
Docker shows me the correct (latest) image
Administration shows me 11.1.4 (so, I can't benefit 11.4.0 features)
Am I doing thing wrong ? When updating, I just change the image version. Everything works well since months, but now...
So ! I solved my problem. I've mounted a volume on /opt/gitlab, and it seems the upgrade doesn't working when the folder already exists. Just don't mount a volume on this folder.
https://docs.gitlab.com/omnibus/docker/#where-is-the-data-stored does not show at any time this folder should be mounted.
Related
Reinstalling gitlab docker issue
So today I messed up accidentally typed docker-compose down instead of stop and since my dockerfile has "latest" tag it tried to update it and it failed now I can't access it.
From my understanding ce version is being discontinued and ee is recommended so I don't mind reinstalling and even loosing my data since there were only two repos anyway but whenever I try to install gitlab-ee:latest I get this error
"It seems you are upgrading from major version 12 to major version 15...."
I did ran docker volume prune and docker system prune -a, but I still get same error. How can I completely delete old ce gitlab and install latest ee version?
Also I'm using laradock so I just replace FROM gitlab-ce:latest to FROM gitlab-ee:latest
From my understanding ce version is being discontinued and ee is recommended
Not that I know of. gitlab-ce Docker image is very much maintained.
And you could reinstall the 12.10.14-ce.0, which would still be compatible with your old version.
By using a FROM gitlab/gitlab-ce:12.10.14-ce.0 instead of gitlab/gitlab-ce:latest means that a docker-compose would not accidentally upgrade your GitLab.
Ok so it might be laradock specific but if anyone encounters something similair I did this:
Keep in mind that this will delete all non running images and volumes so make sure that containers you want to leave is running
docker volume prune
docker system prune
And then (in my case) /home/[your_user]/.laradock/data delete everything gitlab related.
It did actually complained when I tried to pull gitlab-ce but did all steps again and gitlab-ee installed without issues.
I've a Symfony project that I am running on my PC with Symfony serve.
This project is on Bitbucket that has IP restrictions, I can only work from home and nowhere else for security reasons, and all works just fine :).
I wanted to create a Docker image so that I can easily change my machine and be able to deploy it elsewhere.
So I created a Docker image and did the necesseray configurations and all seems good, I can open the project and work the same way as before. The Docker has the default WSL (WSL1) and I've noticed that the application isn't running as fast as usual (outside the Docker, to load a page it would take 3 seconds, while with Docker it takes at least 30 seconds).
I did some research and found out that I could use the WSL2 with DOCKER which provides better performance than the legacy Hyper-V Backend and Enabled integration for the distro UBUNTU-20.4. The problem using the WSL2 is that I am no longer able to pull my project in the WSL2 (from the Ubuntu-20.0) because of the IP restrictions.
It is really strange that I cannot find any configuration for this and I have no idea what should I do to change it. If I pull the project outside the WLS2 distro it works, with the default WSL it works also but not with the WSL2.
I removed the IP restrcitions and the Docker image worked fine, I have the same speed as If I was outside the Docker. The only problem is that I cannot use the IP restrcitoins for this !
Does anyone know how to fix this ? I haven't been able to find any documentation for this issue.
I am using Windows 10 and the Docker version : 4.5.1 (74721)
Thanks a lot for any information.
while deploying docker images on the production server using docker-compose, I got the following error.
Cannot create container for service xxx: open /var/lib/docker/overlay2/969rf5...fdf-init/merged/etc/resolv.conf: Operation not permitted
What I tried:
Changed permissions ( So much so that gave 777 for all the directories involved)
Upgraded kernel (Saw somewhere that it could be kernel issue)
Removed ACL using setfacl -Rb /var/lib/docker
Added the "graph: /var/lib/docker" line in daemon.json
Restarted docker service couple of times.
Tried running the images individually and not using docker-compose.
Tried running with sudo
Set the --storage-opt overlay2.override_kernel_check=1 (Since it is rhel and kernel version supported for docker overlay2 is >4.0, so was suggested to override it.)
I failed everytime!
Have no idea what the issue is or what it could be. Every time I run the docker-compose file, it creates a new directory in /var/lib/docker/overlay2 with old permissions even though I change the permissions for all the other directories in it. At this point I'm not even sure if it is permissions issue or not.
Any help would be appreciated! Thank you!
Finally after trying everything on the internet and nothing working out, the issue was resolved. It was due to the Antivirus that was installed on the server. Had it removed by the client and docker/docker-compose started working absolutely fine.
To give a little more information on the antivirus, it was some FIM antivirus that was installed on a rhel 3.10-xxx which was blocking docker. It was an older version and thank goodness newer versions are compatible with docker. So that's a wrap, thank you all!
On Mac, I'm running Lando inside Docker. I'm on Lando v3.0.1 and was running Docker Desktop v2.2.0.5 successfully.
Docker released stable an update v.2.3.0.3 and I installed it. After that I attempted to run Lando, but got a warning message stating the Docker Desktop version is not supported.
So, I'm wondering if it is possible to roll back to my previous Docker Desktop version without uninstalling Docker.
Download your desired version from the Release Notes.
Open the download, drag "Docker" to "Applications"
Chose to "Replace" the existing installation
Run Docker desktop
All your previous containers should still be there.
If you're using Docker Desktop, I found deselecting the option Use Docker Compose V2 fixed my problems. Spent a long time working on reinstalling things. Definitely worth a try before doing anything big.
[Answer 2022]
As said #patricknelson
Sadly, this no longer works. Now it only says "Existing installation is up to date".
And workaround of Docker Descktop downgrade with retains of the data described below:
Get a list of containers
docker container ls
Commit the container to save the data:
docker commit -p 64bf7c9f7122 new-image
where 64bf7c9f7122 - id of my container
new-image - new image name
Save the committed image with changes to the archive
docker save -o c:\backup.tar new-image
Delete current Docker Desktop
Install desired Docker Desktop version
Unpacking the image in docker
docker load -i c:\backup.tar
run container
docker run --name sample-container new-image
Congrats, all data saved and Docker downgraded 😃
So, I run the installer of the previous Docker Desktop version: 2.2.0.5 - got a warning message stating that a newer Docker already exists and if I wanted to replace it (stop, or keep it both). I selected 'Replace'.
The installation went successful.
But when I open Docker all my running containers were gone.
I run lando to recreate my Drupal 7 site.
I got the "Boomshakala" from lando confirming that the app has started up correctly, and provided with its corresponding vitals -including the APPSERVER URLS.
But when I access the URL, I got an error message:
"Error: the website encounter an unexpected error. Please try again later."
The uncaught exception thrown in shutdown function:
"PDOException: SQLSTATE[]: Base table or view not found:1146 Table 'drupal7.semaphore' doesn't exist...."
To solve this, I imported and old copy of the drupal database site:
lando db-import .sql
then I navigated to the docroot folder, and run a database update:
lando drush upddatedb
All good now; thanks #halfer for your comments!
The quick hack here for Lando specifically, is just to reinstall Lando from the installer for the version you want. We've bundled the supported version of Docker Desktop with Lando itself which means you can always specifically install the supported version when installing Lando. This may wipe out your containers and volumes, so be careful!
Good Day:
I have been trying to create an Odoo 12 community version container on Docker in Synology DSM. Which source/tag should I use for this purpose?
The following source is the one I have been working with directly from Synology Docker:
https://hub.docker.com/_/odoo/
(Tag: Latest)
The only thing I have been able to do is creating a container for Odoo 12 enterprise, but not for Odoo 12 community.
Please advise.
Regards,
The official Odoo docker version is currently from date 2018-10-08 and it had a bug that showed incorrectly Enterprise version in Settings page also in Community version. So the good news is that you are in fact already running Community version. The bug was fixed in this commit.
The more complicated question is what version of docker image should you run. The official Odoo docker image (library/odoo or _/odoo or just odoo) does not get updated very frequently. It is not updated to fix issues. I would not recommend it for any other use than testing.
You can use other images that are updated more frequently and have static tags, e.g. I maintain an image with nightly Odoo builds. It is named veivaa/odoo. You can use a specific version of Odoo nightly build with tag version-date, e.g. veivaa/odoo:12.0-20181106. The nightly image can be found in Docker store at https://store.docker.com/community/images/veivaa/odoo. This version is updated on ”best effort” bases.
You find more information on running Odoo in Docker in my blog.
It is also not best practice with Docker to use the latest tag in production use or if you need to be able to keep the container stable. This is because you would get a different version depending on when you pull the image. Best practice is to either use a stable nonchanging tag, or build your own Dockerfile and image in own container registry.