What is the latest stable image in docker hub?

Help
1

hi Community,
What is the latest stable image in the docker hub?
That one with the latest tag?
https://hub.docker.com/r/speckle/speckle-server/tags?page=1&ordering=last_updated

2

Hi @bgarcial ,

Here’s a quick description of docker image tags used on our published images:

  • [github_commit_id] for all commits in main branch
  • [release_name] for all releases
  • latest for the latest commit in main branch
  • 2 for the latest release

So we’re moving quite fast and things change frequently, so there is currently no official stable version as we’re still in beta, but the 2 tag should allow to use our latest release (we usually release when things are considered stable, and if we find any issue with the latest release, we prioritize releasing a new version with the fix as soon as possible).

Also, in case you missed it, we recently put a DigitalOcean Marketplace App with the Speckle Server and all it’s components (currently redis, postgresql, speckle server, frontend, preview service).
It uses docker compose to spin them all up, and allows for easily updating to new versions.

Here’s how to use the DigitalOcean Marketplace App: Deploying a Server - DigitalOcean Marketplace App | Speckle Docs

Here’s some docs about manually setting things up: Deploying a Server - manual setup | Speckle Docs

Cristi

1 Like
3

Thanks @cristi
It was clear to me about releasing process.
What is the difference between Speckle server, frontend, and viewer?
I have been working with a Speckle v1 deployment but I am still don’t know about the differences between those ones.

In Specklev1 we have SpeckleAdmin as a plugin, is it the same as the frontend for Specklev2?

Is the packages directory (on Specklev2) the equivalent to the plugins directory we had in Specklev1?

I would like to know more about those components within Speckle application context.

4

Hi @bgarcial! Things have changed a bit. The packages directory holds… many things, some unrelated to the server. It’s because we switched to a monorepo to keep all our javascript in one place. Makes it easier for dev!

The frontend (what was called admin in v1) is again, a “plugin”, albeit one with a more central role. Nevertheless you don’t have to bother with it since @cristi sorted things out with docker - so deployments are more of a breeze.

The plugins directory in v1 never really made it far. We have now a much more powerful and proper architecture for extending the server - see this tutorial that @Alan wrote: Creating Your Own App | Speckle Docs

I’ll ping you in private, we’re curious what you’re up to :slight_smile:

5

Thanks @dimitrie
And, what about the viewer?

Actually in our team (in Royal Haskoning, the company where I work), we have a Speckle v1 service implementation deployed on Kubernetes cluster on Azure. Here I share some general facts about the what we are doing:

  • We use this cluster for many Speckle customer deployments.

  • We are using Azure Active Directory Authentication having an Azure AD group per customer, and inside that group we have the users of that deployment, and a service principal to allow the Azure AD authentication just for that Speckle instance.

  • We are restricting access to speckle instances just to the users groups members, by working with app roles assignments to make a kind of association/relationship, between Azure AD group, users inside it, and the service principal. So in this way users that does not belong to the group will not login to Speckle instance.

Now we want to replicate a similar workflow for Speckle v2, and some of our main concerns or things I am wondering are:

  1. How can we take advantage of the continuous releases you are doing and @cristi described well above? We want as an ideal scenario, to get all the stable updates within our deployment.

What I am thinking is to make use of the speckle server stable (tag 2) image and fetch it from our helm chart, but not sure about how safe or advisable will be to use the public image.
What was done in our Speckle v1 was that a customize repository was done (it was forked from yours) and we build and push the image to our private container registry. Similar to this option

  1. In our speckle v1 deployment we are using Azure Application Gateway for Load Balancing purposes, and within Kubernetes we use Azure application gateway Ingress Controller.

One of the reasons behind using this ingress controller was to make it easier to use it with Azure App Gateway, due to was necessary to think about WebSockets support being Speckle v1 a NodeJS application. The thing is that apparently some of the clients like grasshopper or Revit were requiring to have this support that only could be met by the azure app gateway.
I was wondering if I can use NGINX as an ingress controller now for Speckle V2. I think it should work as well. Not sure.

What are your thoughts about those infrastructure and Continuous delivery concerns?

(*Sorry, I know these questions perhaps should have to be included in a new question.)

6

Our latest “stable” release usually spends around a week or more in our internal testing environment before it’s moved in production (via 2.x.x tag). Sometimes we do push out new releases faster, this happens when we have a critical bug fix in the pipe. So your planned strategy is sound :sunglasses:

Other than that I think it’s up to you. As I might’ve mentioned before, we can’t do free support or consultancy on server deployments - this is because we’re trying to build a sustainable open source company & project, so we need to find a way to pay the bills and keep the work going.

This brings me to another point (even more off topic; but it’s late so…) - what would you be willing to pay for? RHDV is in obvious good hands with you, but if there’s anything you’d like to share on the matter more than happy to hear and discuss! We want to have these conversations as much as we can in the open, as we’re keen to align company interests with community interests :slight_smile:

1 Like
7

@dimitrie
I understand about questions regarding server deployments. Is late and I just was thinking in ask this. And of course it is part of your core business which allow to keep going with Speckle as an OS project.
So far we want to deploy Speckle v2 in our internal company azure tenant. We think the current template infrastructure we have for Speckle v1 could be a good starting point, and adding a PostgreSQL deployment (and removing MongoDB from the stack.)
So far this is still in planning, but for sure if I got some questions we will keep in mind your thoughts and potential support :slight_smile: