This repo has been deprecated

As of January 9, all steps run during a Codeship Pro build run in a dedicated network. Instead of relying on a script to get IPs of containers, you can easily communicate with them inside each step by referencing the service name as the hostname.

For example, given this services file:

app:
  image: my_application_image
database:
  image: postgres:10

I can communicate with the database container by referencing just database:

inside the app container

root@d232877f67f5:/# ping database PING db (172.25.0.2) 56(84) bytes of data. 64 bytes from jet-db-run-tests.sleep_5m (172.25.0.2): icmp_seq=1 ttl=64 time=0.089 ms

You can read more about these new features on our blog.

Get the IP of a running container during a Codeship Pro build

You can run jet steps against this repo to see example output. Download the Jet CLI.

In some cases, you may need to get the IP of a running container during a Codeship Pro build, and links won't suffice -- likely because you need bidirectional communication between containers.

In this example, app1 and app2 must be able to communicate with one another. Since containers running during a Codeship Pro build don't run on the same network (yet!), we'll have to get addresses and ports manually.

In this scenario, app1 knows how to comminicate to app2 via the env vars set from the link. app2 knows where to find app1 from extra step we'll add below that will set the IP address of app1 in an env file.

Add a Docker service to codeship-services.yml

Create a docker service that will be able to inspect containers running on the host system. We'll use this service to find the IP, and then write that to an env file that you other services can consume via a mounted volume.

docker:
  build: .
  add_docker: true
  volumes:
    - ./tmp:/tmp
  links:
    - app2

Add the bin/get_service_ip script to a setp to get the IP address for the desired container

There's a little script at bin/get_service_ip that will filter running containers by image name, then inspect that container. We can get the IP address from the inspect results using handy formatting. You need to change this script to suit your needs. There are several filtering options.

Then, print out that value to an env file. The file is shared across containers via the volume.

There's also a handy printenv step for app2 just to verify that the env vars generated by the link to app2 are being set appropriately (and automatically).

IP Address != service readiness

Note that existence of an IP address doesn't mean that the service is healthy or consumable. You'll still need to add a healthcheck or other script to wait for service readiness.