{"action":"created","issue":{"url":"https://api.github.com/repos/drone/drone/issues/1268","labels_url":"https://api.github.com/repos/drone/drone/issues/1268/labels{/name}","comments_url":"https://api.github.com/repos/drone/drone/issues/1268/comments","events_url":"https://api.github.com/repos/drone/drone/issues/1268/events","html_url":"https://github.com/drone/drone/issues/1268","id":113715413,"number":1268,"title":"Support separate bridge networks and linking","user":{"login":"armab","id":1533818,"avatar_url":"https://avatars.githubusercontent.com/u/1533818?v=3","gravatar_id":"","url":"https://api.github.com/users/armab","html_url":"https://github.com/armab","followers_url":"https://api.github.com/users/armab/followers","following_url":"https://api.github.com/users/armab/following{/other_user}","gists_url":"https://api.github.com/users/armab/gists{/gist_id}","starred_url":"https://api.github.com/users/armab/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/armab/subscriptions","organizations_url":"https://api.github.com/users/armab/orgs","repos_url":"https://api.github.com/users/armab/repos","events_url":"https://api.github.com/users/armab/events{/privacy}","received_events_url":"https://api.github.com/users/armab/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/drone/drone/milestones/8","html_url":"https://github.com/drone/drone/milestones/Unplanned","labels_url":"https://api.github.com/repos/drone/drone/milestones/8/labels","id":1261089,"number":8,"title":"Unplanned","description":"No plan to fix in any specific release. Note that this doesn't mean we `wontfix`, just that it isn't scheduled for an upcoming release.","creator":{"login":"bradrydzewski","id":817538,"avatar_url":"https://avatars.githubusercontent.com/u/817538?v=3","gravatar_id":"","url":"https://api.github.com/users/bradrydzewski","html_url":"https://github.com/bradrydzewski","followers_url":"https://api.github.com/users/bradrydzewski/followers","following_url":"https://api.github.com/users/bradrydzewski/following{/other_user}","gists_url":"https://api.github.com/users/bradrydzewski/gists{/gist_id}","starred_url":"https://api.github.com/users/bradrydzewski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bradrydzewski/subscriptions","organizations_url":"https://api.github.com/users/bradrydzewski/orgs","repos_url":"https://api.github.com/users/bradrydzewski/repos","events_url":"https://api.github.com/users/bradrydzewski/events{/privacy}","received_events_url":"https://api.github.com/users/bradrydzewski/received_events","type":"User","site_admin":false},"open_issues":57,"closed_issues":21,"state":"open","created_at":"2015-08-18T17:49:47Z","updated_at":"2015-11-28T04:19:04Z","due_on":null,"closed_at":null},"comments":4,"created_at":"2015-10-28T00:07:46Z","updated_at":"2015-12-06T21:17:21Z","closed_at":null,"body":"#### Preamble\r\nIn Drone `v0.3` it was possible to access linked services by hostname.\r\nIn `v0.4` it was replaced with logic that [all services are available via `127.0.0.1`](http://readme.drone.io/build/services.html) only.\r\n\r\nFor most of the users `v0.4` approach is very useful and saves the time, also it's the same as we have in other well-known CI systems. However there are more complex configurations.\r\n\r\n#### The problem\r\nFor exampe when not only `mongo`/`mysql`/another database is needed and there are many docker containers talk to each other by host and do complex things with ssh/scp, which is not possible on `127.0.0.1` due to port conflicts.\r\nThe strongest reason is to be better compatible with complex configurations defined in [`docker-compose.yml`](https://docs.docker.com/compose/), which uses the same approach with networking. Related issue https://github.com/drone/drone/issues/906 shows that it's pretty popular way.\r\n\r\nYou can have complex orchestration rules in `docker-compose` and port that logic into Drone CI. Defnitely cool!\r\n\r\n#### Proposal\r\nAdd an option in `compose` section to access linked services by hostname.\r\n\r\nIn that case in `.drone.yml` config: \r\n```yaml\r\ncompose:\r\n  cache:\r\n    image: redis\r\n  database:\r\n    image: postgres\r\n```\r\n`cache` and `database` would be hostnames injected into `/etc/hosts` of all containers.\r\n\r\n------\r\n\r\nI believe it would be super-helpful to find the way to be more compatible with `docker-compose` configurations, ideally to make CI run and `docker-compose` runs reproducible.\r\n"},"comment":{"url":"https://api.github.com/repos/drone/drone/issues/comments/162348246","html_url":"https://github.com/drone/drone/issues/1268#issuecomment-162348246","issue_url":"https://api.github.com/repos/drone/drone/issues/1268","id":162348246,"user":{"login":"bradrydzewski","id":817538,"avatar_url":"https://avatars.githubusercontent.com/u/817538?v=3","gravatar_id":"","url":"https://api.github.com/users/bradrydzewski","html_url":"https://github.com/bradrydzewski","followers_url":"https://api.github.com/users/bradrydzewski/followers","following_url":"https://api.github.com/users/bradrydzewski/following{/other_user}","gists_url":"https://api.github.com/users/bradrydzewski/gists{/gist_id}","starred_url":"https://api.github.com/users/bradrydzewski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bradrydzewski/subscriptions","organizations_url":"https://api.github.com/users/bradrydzewski/orgs","repos_url":"https://api.github.com/users/bradrydzewski/repos","events_url":"https://api.github.com/users/bradrydzewski/events{/privacy}","received_events_url":"https://api.github.com/users/bradrydzewski/received_events","type":"User","site_admin":false},"created_at":"2015-12-06T21:17:20Z","updated_at":"2015-12-06T21:17:20Z","body":"@jakubsacha see issue https://github.com/drone/drone/issues/906 for importing a docker compose file as part of the yaml. This is definitely planned as a convenience to auto-populate the compose section. It would look something like this:\r\n\r\n```\r\n-compose:\r\n-  database:\r\n-    image: mysql\r\n+compose: path/to/docker-compose.yml\r\n```\r\n\r\na few things to consider ...\r\n\r\n**First** is that many teams using Drone are not using Docker for deployment. We don't want to enforce an advanced level of Docker knowledge to use Drone.\r\n\r\n**Second** is that many people building libraries are not using Docker. If you assume that 9 of 10 repositories on GitHub are libraries, and not applications, we don't want to enforce Docker knowledge to use Drone.\r\n\r\n**Third** is that Drone has much more complex orchestration requirements than provided by `libcompose`, including running sequential, parallel and chained tasks, managing plugins and more. The `compose` section simply re-uses Drone's internal orchestration engine. We compile the Yaml to an AST representation, and we are good to go!\r\n\r\nUsing `libcompose` for the the `compose` section is certainly be possible, however, it wouldn't eliminate the need for Drone's internal orchestration engine. It would likely require a lot of code to have two engines working together, with security and sanization that we have today.\r\n\r\nIf you consider that supporting a field in Docker compose is **usually** around three lines of code [1] and that we would still need our own internal engine, I think using `libcompose` is more work than maintaining feature parity.\r\n\r\nLinking and named containers are the exception, however, and will require a bit more code. I personally don't think it is enough code to justify the concerns with `libcompose`. I definitely appreciate the suggesting, and would encourage you to dig deeper into the orchestration code and let me know if you agree with my assessment.\r\n\r\n[1] https://github.com/drone/drone-exec/commit/6b5e5a1118c8edab59a9aca8efc035bad80ca2cc"}}