CODEWITHSUNDEEP
imagedockerdocker-composecontainers
Casey Harrils
Casey Harrils

Reputation: 2963

creation of container using docker-compose deletes another container that is already running

I am trying to start 2 separate containers using the docker-compose command based on 2 different images.

One image (work) is based on code worked on in "development". A second image (cons) image is created by code that is currently at the "consolidation" level.

When starting the first container, all seems to go OK.

enter image description here

Details of above image are here:

WORK DIRECTORY: ~/apps/django.work/extraction/docker-compose.yml

version: '3'

services:
  db:
    image: postgres
    container_name: postgres-work           
  web:
    build: .
    image: apostx-cc-backoffice-work        
    container_name: cc-backoffice-work      
    command: python3 backendworkproj/manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "7350:8000"
    depends_on:
      - db

EXECUTION:~/apps/django.work./extraction$ docker-compose up --no-deps -d web

Creating network "extraction_default" with the default driver
Creating cc-backoffice-work ...
Creating cc-backoffice-work ... done

EXECUTION:~/apps/django.work/extraction$ docker container ls

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                    NAMES
39185f36941a        apostx-cc-backoffice-work   "python3 backendwo..."   8 seconds ago       Up 7 seconds        0.0.0.0:7350->8000/tcp   cc-backoffice-work
dede5cb1966a        jarkt/docker-remote-api     "/bin/sh -c 'socat..."   2 days ago          Up 2 days           0.0.0.0:3080->2375/tcp   dock_user_display_remote

But, when I work with the second directory to compile and start a different image, some strange things start to happen:

enter image description here

Again, more details are below:

CONS DIRECTORY: ~/apps/django.cons/extraction/docker-compose.yml

version: '3'

services:
  db:
    image: postgres
    container_name: postgres-cons         
  web:
    build: .
    image: apostx-cc-backoffice-cons      
    container_name: cc-backoffice-cons    
    command: python3 backendworkproj/manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "7450:8000"
    depends_on:
      - db

EXECUTION:~/apps/django.cons/extraction$ docker-compose up --no-deps -d web

Recreating cc-backoffice-work ...
Recreating cc-backoffice-work
Recreating cc-backoffice-work ... done

EXECUTION:~/apps/django.cons/extraction$ docker container ls

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                    NAMES
f942f84e567a        apostx-cc-backoffice-cons   "python3 backendwo..."   7 seconds ago       Up 6 seconds        0.0.0.0:7450->8000/tcp   cc-backoffice-cons
dede5cb1966a        jarkt/docker-remote-api     "/bin/sh -c 'socat..."   2 days ago          Up 2 days           0.0.0.0:3080->2375/tcp   dock_user_display_remote

Question

Why is the first container being supplanted when I start the second one? If it is due to some kind of caching issue, how can one re-initialize/clean/clear out the cache before running docker-compose for a second time? Am I missing something here?

TIA

Update - I did the following:

  1. got rid of old containers by using "docker container rm -f "

-

  1. started the "work" (i.e. development) container

execute:~/apps/django.work.ccbo.thecontractors.club/extraction$ docker-compose --verbose up --no-deps -d web >& the_results_are_here

execute:~/apps/django.work.ccbo.thecontractors.club/extraction$ docker container ls

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                    NAMES
61d2e9ccbc28        apostx-cc-backoffice-work   "python3 backendwo..."   4 seconds ago       Up 4 seconds        0.0.0.0:7350->8000/tcp   work-cc-backoffice
dede5cb1966a        jarkt/docker-remote-api     "/bin/sh -c 'socat..."   3 days ago          Up 3 days           0.0.0.0:3080->2375/tcp   dock_user_display_remote
9b4b8b462fcb        wmaker-test-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7700->8080/tcp   testBackOfficeWork.2017.10.30.04.20.01
ad5fd0592a07        wmaker-locl-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7500->8080/tcp   loclBackOfficeWork.2017.10.30.04.20.01
7bc9d7f94828        wmaker-cons-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7600->8080/tcp   consBackOfficeWork.2017.10.30.04.20.01
  1. seeing that it looks OK, started the container for "cons" (consolidation)

execute:~/apps/django.cons.ccbo.thecontractors.club/extraction$ docker-compose --verbose up --no-deps -d web >& the_results_are_here

execute:~/apps/django.cons.ccbo.thecontractors.club/extraction$ docker container ls

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                    NAMES
0fb24fc45877        apostx-cc-backoffice-cons   "python backendwor..."   5 seconds ago       Up 4 seconds        0.0.0.0:7450->8010/tcp   cons-cc-backoffices
dede5cb1966a        jarkt/docker-remote-api     "/bin/sh -c 'socat..."   3 days ago          Up 3 days           0.0.0.0:3080->2375/tcp   dock_user_display_remote
9b4b8b462fcb        wmaker-test-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7700->8080/tcp   testBackOfficeWork.2017.10.30.04.20.01
ad5fd0592a07        wmaker-locl-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7500->8080/tcp   loclBackOfficeWork.2017.10.30.04.20.01
7bc9d7f94828        wmaker-cons-officework      "catalina.sh run"        11 days ago         Up 11 days          0.0.0.0:7600->8080/tcp   consBackOfficeWork.2017.10.30.04.20.01
  1. Again, the name: work-cc-backoffice has been supplanted by name: cons-cc-backoffices - work-cc-backoffice is totally gone now.

-

  1. Looked at the file the_results_are_here (in the second run) to see if anything can be found
[... snip ...]

compose.cli.command.get_client: docker-compose version 1.17.1, build 6d101fb
docker-py version: 2.5.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.4.0-72-generic, Arch=amd64, BuildTime=2017-09-26T22:40:56.000000000+00:00, ApiVersion=1.32, Version=17.09.0-ce, MinAPIVersion=1.12, GitCommit=afdb6d4, Os=linux, GoVersion=go1.8.3
compose.cli.verbose_proxy.proxy_callable: docker info <- ()
compose.cli.verbose_proxy.proxy_callable: docker info -> {u'Architecture': u'x86_64',

[... snip ...]

compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- (u'extraction_default')
compose.cli.verbose_proxy.proxy_callable: docker inspect_network -> {u'Attachable': True,
 u'ConfigFrom': {u'Network': u''},
 u'ConfigOnly': False,
 u'Containers': {u'61d2e9ccbc28bb2aba918dc24b5f19a3f68a06b9502ec1b98e83dd947d75d1be': {u'EndpointID': u'e19696ccf258a6cdcfcce41d91d5b3ebcb5fffbce4257e3480ced48a3d7dcc5c',
                                                                                       u'IPv4Address': u'172.20.0.2/16',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:ac:14:00:02',
                                                                                       u'Name': u'work-cc-backoffice'}},
 u'Created': u'2017-11-10T09:56:22.709914332Z',

 u'Driver': u'bridge',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={u'label': [u'com.docker.compose.project=extraction', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 1 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'61d2e9ccbc28bb2aba918dc24b5f19a3f68a06b9502ec1b98e83dd947d75d1be')
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'docker-default',
 u'Args': [u'backendworkproj/manage.py', u'runserver', u'0.0.0.0:8000'],
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'python3',
                      u'backendworkproj/manage.py',
                      u'runserver',
                      u'0.0.0.0:8000'],
             u'Domainname': u'',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=extraction', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 1 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'61d2e9ccbc28bb2aba918dc24b5f19a3f68a06b9502ec1b98e83dd947d75d1be')
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'docker-default',

To me, it looks like the program is trying to do some initialization by looking for a container that is already up and running(?) See pic. below. How can one change this behavior

enter image description here

Upvotes: 1

Views: 175

Answers (1)

Casey Harrils
Casey Harrils

Reputation: 2963

Answer from @mikeyjk resolved the issue.

No worries. I wonder if you give each service a unique name, re run composer build, whether the issue still occurs. I'll try and replicate it today if no-one can work it out

Upvotes: 1

Related Questions