Autodeploy service for dev

[antho1404]

With the new services deployed from tar and the new kind of system services that are just services #725 we need a way to easily work and deploy local services locally and for production a way to configure the endpoint of the services we will want for the release.

For that few things:

• dev and prod Configurable variable in the config package with the URL of the services with the format ServiceURL
• dev A server that contains all the services archives from the systemservices directory
• dev A script dev-core that inject the services tar endpoint from the server created

This way we now have a way to configure the address of the services needed by the core during the compilation (and can be integrated in the CI) and a way in development to work with the local directory without any hack on the code base, just on the dev tools.

[NicolasMahe]

The function deleteServiceServer in dev-core script doesn't work if there is no service core-service-server.

I add some output to see what happen:

function deleteServiceServer {
  echo "1"
  rm -rf tmp-systemservices
  echo "2"
  serviceExists=$(docker service list | grep core-service-server)
  echo "3"
  if [[ "$serviceExists" != "" ]]; then
    echo "4"
    docker service rm $MESG_SERVICE_SERVER
    echo "5"
  fi
  echo "6"
}

➜  core git:(feature/autodeploy-service-for-dev) ✗ ./dev-core
1
2

and then the script stop with an error code (the terminal indicator is red).

[antho1404]

Can you please review @krhubert @ilgooz

[krhubert]

What is the purpose of initServices?

[antho1404]

It's called from the config, it's to have all the logic about the services in the same folder instead of having to initialize it on the config.go but declare it here

[ilgooz]

This is an interesting PR. This approach wouldn't be my first choice. Instead we could find out and deploy local services from systemservices folder by their path, programmatically, in the config pkg depending on the env (dev or prod).

Because creating a tar for all services will produce an overhead under active development. If we do this with Go, we were just going to pass an io.Reader produced by the archiver func which means archiving process was going to be made on the fly while sending the context to Docker daemon. But with this approach we're waiting the archiving to be finished and then sending it to Docker.

I understand the idea behind of this new script. We didn't want to add env(dev/prod) related deployment rules to Core for simplicity. But to me it's not a problem, infact maybe better because it's easier to code in Go and bash commands doesn't work in every OS without having additional tools. So no need to heavily depend on that. And we lose more on IO time this way with pre archiving services also, we cannot do parallel deployments...