meli

Meli is supposed to be a faster, and drop in, alternative to docker-compose. Faster in the sense that, Meli will try to pull as many services(docker containers) as it can in parallel.

Meli is a Swahili word meaning ship; so think of Meli as a ship carrying your docker containers safely across the treacherous container seas.

It's currently work in progress, API will remain unstable for sometime.

I only intend to support docker-compose version 3+

Meli is NOT intended to replicate every feature of docker-compose, it is primarily intended to enable you to pull, build and run the services in your docker-compose file as fast as possible.
If you want to exec in to a running container, use docker; if you want to run an adhoc command in a container, use docker; if you want..... you get the drift.

Installing/Upgrading

Download a binary release for your particular OS from the releases page
We have binaries for:

linux(64bit)
windows(64bit)
macOS(64bit)

Usage

meli --help

Usage of meli:
  -up
    	Builds, re/creates, starts, and attaches to containers for a service.
        -d option runs containers in the background
  -f string
    	path to docker-compose.yml file. (default "docker-compose.yml")
  -build
    	Rebuild services
  -v	Show version information.
  -version
    	Show version information.

cat docker-compose.yml

version: '3'
services:
  redis:
    image: 'redis:3.0-alpine'
    environment:
      - RACK_ENV=development
      - type=database
    ports:
      - "6300:6379"
      - "6400:22"

meli -up

redis :: Pulling from library/redis 
redis :: Pulling fs layer 
redis :: Pulling fs layer 
redis :: Downloading [======================>        ]  3.595kB/8.164kB
redis :: Downloading [==============================>]  8.164kB/8.164kB
redis :: Download complete [========================>]  8.164kB/8.164kB
redis :: The server is now ready to accept connections on port 6379

Usage as a library

You really should be using the official docker Go sdk
However, if you feel inclined to use meli;

package main

import (
	"context"
	"log"
	"os"

	"github.com/docker/docker/client"
	"github.com/komuw/meli"
)

func main() {
	dc := &meli.DockerContainer{
		ComposeService: meli.ComposeService{Image: "busybox"},
		LogMedium:      os.Stdout,
		FollowLogs:     true}

	ctx := context.Background()
	cli, err := client.NewEnvClient()
	if err != nil {
		log.Fatal(err, " :unable to intialize docker client")
	}
	defer cli.Close()

	meli.LoadAuth() // load dockerhub info
	err = meli.PullDockerImage(ctx, cli, dc)
	log.Println(err)

}

Benchmarks

Aaah, everyones' favorite vanity metric yet no one seems to know how to conduct one in a consistent and scientific manner.
Take any results you see here with a large spoon of salt; They are unscientific and reek of all that is wrong with most developer benchmarks.

Having made that disclaimer,

Benchmark test:
this docker-compose file

Benchmark script:
for docker-compose:
docker ps -aq | xargs docker rm -f; docker system prune -af; /usr/bin/time -apv docker-compose up -d
for meli:
docker ps -aq | xargs docker rm -f; docker system prune -af; /usr/bin/time -apv meli -up -d

Benchmark results(average):

tool	Elapsed wall clock time(seconds)
docker-compose	10.411 seconds
meli	3.945 seconds

Thus, meli appears to be 2.6 times faster than docker-compose(by wall clock time).
You can checkout the current benchmark results from circleCI
However, I'm not making a tool to take docker-compose to the races.

Development

Build

git clone git@github.com:komuw/meli.git
go build -o meli cli/cli.go
./meli -up -f /path/to/docker-compose-file.yml

debug

go build -o meli cli/cli.go
dlv exec ./meli -- -up -f testdata/docker-compose.yml
(dlv) help
(dlv) break cli/cli.go:246
(dlv) continue

TODO

add better documentation(godoc)
stabilise API(maybe)

galtsev/meli