Port forwarding in drone services

Drone Support
1

Hi there,

I have a pipeline that runs quite a lot of supporting services for various test scenarios executed by gradle. Because of gradle I don’t want to move them to independent steps, but this means that 2 of these supporting services are the same thing, with slightly different configuration. The problem is obviously that the service port is identical in this case, and I can’t figure out if port forwarding is functional in services. I can hit them over the default service port, but the forwarding rules used in compose fail to unmarshall in yaml and without the mapping

  • 9001:9000
    it doesn’t do anything.

Is this meant to be functional / is there an alternative to this?

---
kind: pipeline
type: kubernetes
name: smoke-artefact-layers

platform:
  os: linux
  arch: amd64
  
environment:
  registry: xy
  
workspace:
  path: /drone/src

depends_on:
  - linting
  
services:
- name: dind-engine
  image: docker:dind
  privileged: true
  commands:
  - dockerd --host=tcp://0.0.0.0:2375
  
- name: minio1
  image: minio/minio
  commands:
  - minio server /data
  environment:
    MINIO_ACCESS_KEY: secret1
    MINIO_SECRET_KEY: secret2
  ports:
    - 9001
  expose:
    - 9000
  
- name: minio2
  image: minio/minio
  commands:
  - minio server /data
  environment:
    MINIO_ACCESS_KEY: secret3
    MINIO_SECRET_KEY: secret4
  ports:
    - 9002
  expose:
    - 9000

steps:
- name: build
  image: docker:dind
  privileged: true
  environment:
    DOCKER_HOST: tcp://dind-engine:2375
  commands:
    - |
      tests in gradle commands to connect to minio1 and minio2

trigger:
  branch:
  - master
  event:
  - pull_request
  - push

Cheers,
George

2

when you are using the kubernetes runner, all containers (including service containers) run on the same Pod and therefore share the same localhost network. There is no port mapping. Instead you should use command line flags to change the default Minio port, perhaps with the --address flag?

3

Yeah I ended up going that way, realised that the port mapping wont help in the pod. I think maybe this is worth going into the docs though as for kind: docker it may work fine. I think people won’t know the syntax outright as the normal would be port:port whereas this is:

  ports:
  - port: source_port
    host: mapped_port
    protocol: TCP

if I understand correctly.

4 
  ports:
  - port: source_port
    host: mapped_port
    protocol: TCP

The above syntax was from an experimental version of our kubernetes integration that required port mapping because service containers ran as Kubernetes services. This is no longer the case. In our current implementation, service containers run in the same Pod as pipeline steps and are addressable at localhost.

1 Like