We have a microservice based app that uses Azure ServiceBus. We deploy one of the services (a saga manager) as a .Net Core console app in a docker container (Linux). We use docker-compose and a group of 2 containers (including the console app) is deployed into an Azure Container Instance.
We use MassTransit for working with Azure ServiceBus.
The console app (saga manager) starts up the service bus via MassTransit.BusControlExtensions.Start() method.
More or less at this point the console app (saga manager) is primed and ready.
Sidenote: the app in question (saga manager) runs an Automatonymous State Machine
Now if we stop or delete the container with the saga manager, and then restart it - it stops receiving bus messages.
It seems that a new instance of the saga manager (thread?) is created with each restart - while the old instance (thread?) persists somehow.
Even when we delete the Container Instance resource altogether on Azure - we can still observe that the bus messages are picked up by something...
the container's app is still alive after deleting the container group itself
Is there a way to definitively kill the detached instance/thread?
Is anyone familiar with such behavior of Azure Container Instances?
PS in the described scenarios the stop/delete operations are always successful
PS2: here is the yaml file used to deploy the problematic container group with the use of az container create command:
apiVersion: 2018-10-01
location: westeurope
name: #{groupName}#
properties:
containers:
- name: saga-aci
properties:
image: #{acrLoginServer}#/sagaazure:latest
resources:
requests:
cpu: 1
memoryInGb: 1.5
ports:
- port: 80
- port: 443
- port: 9350
- name: proxymanager-aci
properties:
image: #{acrLoginServer}#/proxymanager:latest
resources:
requests:
cpu: 1
memoryInGb: 1.5
ports:
- port: 22999
- port: 24000
osType: Linux
ipAddress:
type: Public
ports:
- protocol: tcp
port: '80'
#- protocol: tcp
#port: '8080'
- protocol: tcp
port: '22999'
- protocol: tcp
port: '24000'
- protocol: tcp
port: '443'
- protocol: tcp
port: '9350'
imageRegistryCredentials:
- server: #{acrLoginServer}#
username: #{acrName}#
password: #{acrPassword}#
tags: null
type: Microsoft.ContainerInstance/containerGroups
perhaps this is a restarpolicy issue?