I read docker support was not ready yet, but docker recently published a preview of their new version that seems to be working. Next issue is that MySQL images are only available on x86_64 and not arm, but MariaDb has one. Unfortunately, I'm not versed enough in Docker to be able to get that working. Finally, I tried installing prisma with a postgres db but couldn't get that working either.
Has anyone had success getting prisma working on the new Apple MC M1 devices? If so, please advise how you got it working.
Edit: Here is the Error Message when I prisma init for a mysql db and run docker-compose up -d
"ERROR: no matching manifest for linux/arm64/v8 in the manifest list entries"
I've come to learn that this is because there isn't a mysql image for arm yet (but there is one for mariadb).
So when I changed the docker-compose file to load the mariadb image instead, docker-compose up -d runs successfully, but when I open http://localhost:4466 in my browser localhost refuses to connect.
The same "localhost refused to connect" result also occurs if I set up prisma for postgres or mongodb too.
Any help is appreciated
Related
All of a sudden I get connection timeouts to our external Postgres server and I am tearing my hairs out of my head to understand why:
hostname = db.ourcompany.com
port = 5432
I can connect via my DB management tool on my desktop, so the DB is working. None of my colleagues have the same issue.
I have upgraded Docker to the latest version.I have removed all containers and images and rebuilt them. I run a Mac M1 on OS 12.6.1. I have not had any recent updates. I can install dependencies within my container which go via Composer or NPM, so external connections go well.
What am I missing? It worked for months, nothing has changed. The docker-compose files are exactly the same as before.
I've just started 'kicking the tires' on Concourse-CI, using the quickstart tutorial as my starting point. That much works fine.
I've created a super basic pipeline with a single task, just like the quickstart tutorial. But instead of pulling the busybox image and executing the echo command, I'm pulling another image, and running a command that would try to update a local postgres db.
When I run the pipeline - my task (docker image writing to local postgres db) fails - because connection can't be made to the local db. I've searched far and wide - and can't seem to figure out how to do this. In the docker-compose from the quickstart tutorial, I've tried adding CONCOURSE_CONTAINERD_ALLOW_HOST_ACCESS: "true" to no avail
Any suggestions on how I may be able to achieve this?
Turns out my issue had nothing to do with Concourse.
The local postgres instance I was attempting to write to was only accepting connections from localhost - which won't allow connections from Docker containers. I updated postgres setting to allow remote connections - and all is well.
I usually use the default network for docker containers, and I had a mongo database running in one just fine and the port was exposed to the network successfully. Then, I tried to attach a new python container to that container using the --link option (yes, I now realize that that is deprecated). An error was thrown, and in my hubris, I didn't capture it, I just went on. Now, when I try to start my mongo database, it fails saying that it can't bind the network. "Failed to set up listener: SocketException: Permission denied"
I removed the container and tried to re-create it, but no luck. I've put this into a permanent state of bad. Any suggestions on how to fix this so I can get my database back?
Thanks.
Edit: Should have mentioned, Ubuntu 20.04, Docker 19.03.11
Also, this only seems to be a problem with any new mongo containers. I can start postgres, and web servers, etc without issues.
Turns out, whatever that error was when I tried to use --link, it had corrupted the mongo image on my machine, so all new instances of that image failed to connect to the network. That's why removing the container and recreating it didn't fix the problem. I needed to delete the local mongo image, and re-pull from the docker hub.
We recently did a GitLab upgrade from 11.x up to 12.9.2. It all went well; however, when I do gitlab-ctl pg-upgrade it shows the DB being 10.12. But when I do gitlab-rake gitlab:env:info it shows 10.7.
If I drop into gitlab-rails dbconsole it shows:
psql (10.12, server 10.7)
I didn't originally set this server or instance up. Any idea why it would be showing two different versions (does 10.12 mean the client is 10.12, the server is still 10.7?) Ideally the server would be 10.12.
Thanks for any help.
Answered my own question after further digging.
I ran a stat on /opt/gitlab/embedded/postgresql/10/bin/postgres and it showed that it was indeed changed when we did the upgrade.
Then I ran an lsof and saw that the postgres process had this binary open with a (deleted) marker, meaning it had the previous file still open in memory.
I ran a gitlab-ctl stop and a gitlab-ctl start and now it's showing properly when I do gitlab-rails dbconsole.
Should've done all that first!
I have installed version 4-1.5, but when opening it, it always shows this error "The application server could not be contacted."
I removed the local directory hidden and resolved:
$ cd ~
$ rm -r .pgadmin/
Note: macOS Sierra (10.12.6) and pgAdmin 4-1.6. Also you are going to loose configuration data like database list tree, et al.
The Databases will remain intact since you are modifying/deleting PgAdmin related data not any of Postgresql itself.
I had the same issue, I fixed it by stopping the service in Postgres app, then start pgAdmin, and then start the Postgres service. I was able to connect it after that. Hope this help.
I had same error, but in my case I use wrong port number for the database
On my system Safari is the problem as it was default browser.
To fix, make Chrome your default browser and try relaunching pgadmin4
OR
Manually fix by
$ cat ~/.pgAdmin4.5704814747986328352.addr
http://127.0.0.1:62631/?key=0ec25e6a-dfe2-483e-9814-b315ea87c3cf
Paste what you get in Chrome