Hello Team Speckle, currently trying to launch a server in a digital ocean droplet and getting an error that seems to derive from the setup.py commands.
This occurs:
Configuring docker containers… unknown shorthand flag: ‘d’ in -d See ‘docker --help’.
then I just get the docker help list and then after that i get the following traceback.
Traceback (most recent call last):
File “/opt/speckle-server/setup.py”, line 225, in
main()
File “/opt/speckle-server/setup.py”, line 174, in main
subprocess.run(
File “/usr/lib/python3.8/subprocess.py”, line 512, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command ‘[‘bash’, ‘-c’, ‘cd “/opt/speckle-server”; docker compose up -d’]’ returned non-zero exit status 125.
You may well be on to something. Historically, docker-compose was the correct form to use when running Docker Compose commands. However, more recent versions of Docker have integrated Docker Compose directly into the Docker CLI, allowing the use of docker compose (without the hyphen).
I haven’t looked at the DO 1-click version of Docker but given the error you’re seeing, it appears that your Docker installation expects the older docker-compose syntax.
I will check more details and see if I can report back.
Hi @jonathon thanks a lot for the quick reply and understood.
I’m not sure if it’s the only problem to be honest as once I’d changed that I managed to get past that step but ended up with a situation where several of the containers were repeatedly restarting over and over. I wonder if there is another similar docker issue somewhere? So for now I stopped fiddling with things!
So for ref, I found it was actually relatively simple to:
Create an ubuntu droplet on digital ocean (recommended with ssh access not password access as it makes moving files easier later with filezilla)
Install docker according to Install Docker Engine on Ubuntu | Docker Docs. Doing it one of the other ubuntu recommended ways totally didn’t work for us so following this guide was key.
While I have your kind attention @jonathon, can I ask a related data-transfer question?
If I wanted to transfer the streams etc. from our older Speckle 2.16 server running in one droplet, to my shiny new Speckle 2.18 server running in a new droplet would the process be basically as per Database backup, upgrade, and restore | Speckle Docs i.e.
Access old server by pgadmin method
generate backup, retrieve from container, download to my pc.
upload from pc to new droplet, copy into pgadmin container.
select new speckle server (which has no models etc. uploaded to it yet - basically have just login to check it all works), hit “restore” and select the backup that I took from the old server.
Is that too simple an understanding or would that end up with the various streams now as projects on the new server?
Thanks for sharing the instructions @jjsolly these are really helpful.
Regarding the data transfer, what you have suggested is what I would try. You may wish to stop your new speckle server while restoring, and then start it again after the restore is complete.
The underlying database structure didn’t fundamentally change as part of the new web app, so the data should be compatible with the new version. Any required changes to the data should be handled by the migration routines in the server when it is started.
Will do, thanks @iainsproat. When you say to stop the server do you mean I should stop all the docker containers other than presumably pgadmin? (apologies if this is a silly query)
Yes, that’s correct - just leave postgres and pgadmin. You don’t want any of the speckle server components trying to write to the database while it’s restoring data.
Seems to have worked well. The only step i didn’t totally understand and confused me for a while was the need to delete the old database first. So the steps were:
use pgAdmin to access
delete the “speckle” database
create a new database called “speckle”
right-click and “restore” onto this the uploaded DB.
When restoring we want to ensure there isn’t existing data with invalid migrations or incompatible version that might corrupt the restored data, hence the requirement for deletion. This is especially likely if upgrading postgres on the same machine. Sounds like you figured it out though.
