4

I'm currently investigating using Mesosphere in production to run a couple of micro-services as Docker containers.

I got the DCOS deployment done and was able to successfully run one of the services. Before continuing with this approach I however also need to capture the development side (not of Mesos or Mesosphere itself but the development of the micro-services).

Are there any best practices how to run a local deployment of Mesosphere in a Vagrantbox or something similar that would enable our developers to run all the services that are in our eco-system from existing docker images and run the one service you are currently working on from a local code folder?

I already know how to link the devs code folder into a Vagrant machine and should also get the Docker part running but I'm still kind off lost on the whole Mesosphere integration part.

Is there anyone who could forward me to some resource in the Internet describing a possible solution for this? Did anyone of you do something similar and would care to share some insights on this?

Michael Hausenblas
  • 13,162
  • 4
  • 52
  • 66
Tim Specht
  • 3,068
  • 4
  • 28
  • 46

2 Answers2

4

Sneak Peak

Mesosphere is actively working on improving the developer experience surrounding DCOS. Part of that effort includes work on a local development cluster to aid application, service, and DCOS package developers. However, the solution is not quite ready for prime time yet. We have begun giving early access to select DCOS Enterprise Edition customers tho. If you'd like to hear more about that, please talk to your sales representative or contact sales through our web site: https://mesosphere.com/contact/

Public Tools

That said, there are many different tools already available that can help when developing Mesos frameworks or Marathon applications.

Disambiguation

Update 2017-08-03

The two currently recommended local development options for DC/OS are:

KarlKFI
  • 3,102
  • 1
  • 15
  • 15
1

I think there's not "the" solution... I guess every company will try to work out the best way to find a fit with their development processes.

My company for example is not using DCOS, but a normal Mesos cluster with clustered Marathon and Chronos schedulers. We have three environments, each running CoreOS and Mesos/Marathon (in different versions, to be able to test against version upgrades etc.):

  • Local Vagrant clusters for our developers for local development/testing (can be configured to use different CoreOS/Mesos/Marathon versions based on the user_data files)
  • A test cluster (virtualized, latest CoreOS beta, latest Mesos/Marathon/Chronos)
  • A production cluster (bare metal, latest CoreOS stable, currently Mesos 0.25.0 and Marathon 0.14.1)

Our build cycle uses a build server (TeamCity in our case, Jenkins etc. should also work fine) which builds the Docker images and pushed them to our private Docker repository. The images are tagged automatically in this process.

We also have to possibility to automatically launch them via Marathon API calls to the cluster defined in the build itself, or they can be deployed manually by the developers. The updated Docker images are thereby pulled from our private Docker repository (make sure to use "forcePullImage": true to get the latest version if you don't use specific image tags).

See

Tobi
  • 31,405
  • 8
  • 58
  • 90
  • Thanks a lot for the insights Tobi! One more question: How do you handle one developer actively working on one microservice while depending on other ones in the environment? This would require the developer to kind of inject his working code into a marathon job running inside mesos, right? – Tim Specht Feb 22 '16 at 08:09
  • Not sure if I understand you correctly... You mean a developer works on one service which relies on others / is part of an application? – Tobi Feb 22 '16 at 08:31
  • Yes, exactly that! So the local mesos cluster would run a couple of services from CI-built container images and the developer would actively work on another service directly from his machine that relies on these CI-built containers – Tim Specht Feb 22 '16 at 09:06
  • Well, if you launch this via Marathon, that means you first have to build the Docker image of the respective service, and then just launch (destroy the old version of the Marathon app and create the new version via the API) the new version of the app. – Tobi Feb 22 '16 at 09:16
  • I know and this would greatly reduce the development speed. Hence I thought it may be possible to directly launch a marathon service from code without building an image before. How are you guys doing this? – Tim Specht Feb 22 '16 at 09:23
  • I think you'll need to build the Docker image, because it's necessary to distribute the artifact. There are (at least) two ways: For local Docker builds, using bash scripting: 1) Build the Docker image locally 2) Push to private repo 3) (Re)Launch Marathon app via curl call. For CI build: 1) Push to Git/SVN repo 2) CI server builds & pushes the Docker image to private Docker repo 3) Manual restart of the Marathon app – Tobi Feb 22 '16 at 10:07