Implement the deployment pipeline for devnet, testnet

[thanhson1085]

We should implement CD (continuous deployment) for devnet, testnet. I suggest 2 steps for the implementation.
the first step, we write deploy.sh script with the expectations below:

• bash deploy.sh tomomaster -> devnet: pull latest image, update container, testnet: pull testnet image, update container
• same above with tomoscan, node ...

Then, we can run command manually to deploy the services.

The second step, we will implement in the future, we will use some CD tool like gitlab-ci, circle-ci to provide the UI, UX. The second step is much easier, we just need to connect CD Tools to trigger a run for deploy.sh script. So team members can track, follow the deployment status via CD Tool UI.

For this issue, we just need to implement the first step.

[etienne-napoleone]

I thought a bit about this, what do you think about using portainer + webhooks

portainer is an web UI in who interact with the Docker daemon.
You can manage services, containers, etc.
It offers some extra functionalties like generating webhooks url to update services, app templates, etc.

With this, we could just add to travis jobs a curl to the webhook, after pushing the new image, to trigger the update and also sent a slack notification. Also, if someone would want to try a specific version in devnet, people can use the portainer UI with access control

[thanhson1085]

Portainer has a little help for this issue, it is for managing containers. This issue is about the deployment.

The deployment scenario is quite complicated, so we should have a script to handle the deployment.

After that,we can setup deployment pipeline, we can use Gitlab CI (or other tools), https://docs.gitlab.com/ce/ci/quick_start/ (low priority)

[etienne-napoleone]

The deployment scenario is quite complicated, so we should have a script to handle the deployment.
After that,we can setup deployment pipeline, we can use Gitlab CI

Release channels and proper versioning of docker images are already taking care of "which version" goes where.

After the build process we have on travis right now, the only missing step is deploying the image.
Before I used a service who will check for new images every 5min it's not ideal and slow.

So we can use a service who wait for a webhook to redeploy. So travis, after pushing the image, can just trigger it to instantly update the service. Also travis can send at this moment a notification via slack for feedback.

Different services propose that. Portainer is one of them. But there is lighter ones who only include this functionality and not the whole docker management.
like this one for ex.: https://github.com/iaincollins/docker-deploy-webhook

I just feel like it's overkill to add bash scripts + another external platform when we could just tweak what we already have

Let me know what you think

[thanhson1085]

We already have good CI with Travis-CI, just need small step - deployment.

So back to the core requirements:

• Deploy services
• View deployment status, history of deployment

You can try your way if it matches the requirement.

If I implement the deployment, I will try to use Travis CI setup deployment pipeline. e.g:

• Build image
• Run test
• Push docker to cloud
• Deploy services (just ssh to server and run deploy.sh or some other commands)

[thanhson1085]

So, with my suggestion, we do not need Portainer or iaincollins/docker-deploy-webhook, just need to update .travis-ci.yml to deploy the services (tomomaster, tomoscan ...)

[etienne-napoleone]

Ok, let's do this.
In the end it's kind of the same. I'm just not a fan of maintaining more shell scripts (because that's actually the most important part).

[thanhson1085]

Yep, looking forward to see the deployment part in .travis-ci.yml file. You can start with tomomaster fistly.
I will change the title of the issue

[etienne-napoleone]

Some problems I need to resolve:

• how to manage the ssh keypairs in travis.
  1 2
• how to provide accurate notifications.
  Error in travis deploy stage are note changing the status to fail.
  1
• how to handle cases where we want to keep a specific version and not be overwritten by the deployments
• might need to create new system user for deployment.
  Deploying from outside with a sudo enabled user might not be a great idea.
  useradd -G docker -M deploy ?

[etienne-napoleone]

might need #54 first

[thanhson1085]

you can do with devnet first, it will deploy latest image

For the testnet, it will deploy testnet image = latest tag.

I think that is a good scenario.

[etienne-napoleone]

Yep for sure, no problem with that, it's the intended goal of those tags.
But I think it's important to have a way to stop the auto updating and fix a version. In case of rollback, or if we want to extensively test a version in devnet without it being overridden every time someone push some code. Need to think about it.

Maybe by getting the list of services who use the specific image and tag. If the service is set to a specific version, it will not get updated.

docker service ls --format "{{.ID}} {{.Image}}" | grep tomochain/tomomaster:testnet

[etienne-napoleone]

https://github.com/dwyl/learn-travis/blob/master/encrypted-ssh-keys-deployment.md

[etienne-napoleone]

Testing implementation on BuildOnViction/tomoscan#413

[etienne-napoleone]

Done for TomoMaster and Tomoscan.