You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that I've tried a few node, docker and docker-compose deploys I'm left with some questions about the general workflow in exoframe. I read up on now.sh deploys (have not used those extensively so I might not be getting the full picture). With now.sh every deploy is immutable and gets a unique url. When time comes to go to production you use now alias to point a domain to one of those deploys. Updating aftwerwards means creating a new deploy and 'pushing those changes live' means adjusting the alias to point to the new deploy.
For exoframe things are a little different and here's what I've noticed so far. If I run exoframe with a baseDomain set I get a unique url. If aftwards I run it again (just exoframe not exoframe -u) I get another unique url but (and this seems like a bug, but it's hard to track down) it seems requests to that url and the last one are now load balanced instead. Updating with exoframe -u afterwards does work and seems to take down the previous containers. This is a bit conflicting because it essentially means it's possible to have only one functioning deploy for each project (for every project name). Even if creating new deploys with exoframe were to function properly it would still require you to know or input which of those you're updating with -u in order not to take down the other containers.
Once you set a domain in exoframe.json I see the same problem. Every time you deploy traefik load balances the requests over the different containers. This is maybe to be expected - or could throw an error ("Use -u to update an already deployed project") but I wonder how it should tie in to an easy workflow. There's often times you want to deploy code changes without seeing them live on the domain you set. And I believe the way now.sh handles it could be a way forward for exoframe too, but I'm not sure how you see this?
The text was updated successfully, but these errors were encountered:
if you are using baseDomain, you'll get new subdomain on each redeployment since the name of deployment includes docker container Id within it. this is pretty much intended.
exoframe -u updates a given project. if you want to keep old versions running you have two options:
(a) don't run with -u flag (then you'll just deploy new version along with old ones),
load balancing over several deployments with same domain is also intended behaviour.
comparing that to now.sh - with current docker version it is sadly not possible to modify container labels on the fly, there is a proposal to implement this feature and once it is landed in docker - I'll definitely add something similar to now alias
Now that I've tried a few node, docker and docker-compose deploys I'm left with some questions about the general workflow in exoframe. I read up on now.sh deploys (have not used those extensively so I might not be getting the full picture). With now.sh every deploy is immutable and gets a unique url. When time comes to go to production you use now alias to point a domain to one of those deploys. Updating aftwerwards means creating a new deploy and 'pushing those changes live' means adjusting the alias to point to the new deploy.
For exoframe things are a little different and here's what I've noticed so far. If I run
exoframe
with abaseDomain
set I get a unique url. If aftwards I run it again (justexoframe
notexoframe -u
) I get another unique url but (and this seems like a bug, but it's hard to track down) it seems requests to that url and the last one are now load balanced instead. Updating withexoframe -u
afterwards does work and seems to take down the previous containers. This is a bit conflicting because it essentially means it's possible to have only one functioning deploy for each project (for every projectname
). Even if creating new deploys withexoframe
were to function properly it would still require you to know or input which of those you're updating with-u
in order not to take down the other containers.Once you set a
domain
inexoframe.json
I see the same problem. Every time you deploy traefik load balances the requests over the different containers. This is maybe to be expected - or could throw an error ("Use -u to update an already deployed project") but I wonder how it should tie in to an easy workflow. There's often times you want to deploy code changes without seeing them live on the domain you set. And I believe the way now.sh handles it could be a way forward for exoframe too, but I'm not sure how you see this?The text was updated successfully, but these errors were encountered: