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
I have a deployment that has limited bandwidth between some forward nodes and their manager. They are low-traffic sites, so there's not much event traffic from the node to the manager, but updates can take a really long time as the docker image is downloaded from the manager to the sensor over that slow link.
It would be handy to be able to stage the next version's images prior to running soup so that it doesn't spend so long with mismatched containers (eg: master has been updated, but sensor is still on previous version waiting for image pulls to complete). I suppose this could be done manually calling docker pull/docker tag/docker push on the master and docker pull on all the sensors, but requires knowledge of which images each node-type needs. Also, beware the call to so-docker-prune if you inadvertently stage more than one future version, or a new version is released after you've already staged the prior version, as it makes some assumptions about which versions should stay.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have a deployment that has limited bandwidth between some forward nodes and their manager. They are low-traffic sites, so there's not much event traffic from the node to the manager, but updates can take a really long time as the docker image is downloaded from the manager to the sensor over that slow link.
It would be handy to be able to stage the next version's images prior to running soup so that it doesn't spend so long with mismatched containers (eg: master has been updated, but sensor is still on previous version waiting for image pulls to complete). I suppose this could be done manually calling docker pull/docker tag/docker push on the master and docker pull on all the sensors, but requires knowledge of which images each node-type needs. Also, beware the call to so-docker-prune if you inadvertently stage more than one future version, or a new version is released after you've already staged the prior version, as it makes some assumptions about which versions should stay.
Beta Was this translation helpful? Give feedback.
All reactions