Hi Ruslan,

The scoped variables are going to be applied to all instances of the container. By having all instances match, it keeps things from behaving unpredictably. Could I ask what you're goal would be by having two instances of the same container receive different values? There may be a better way on Cycle to achieve it.

Hope that helps!

Hi Alexander!

Currently, I have an application running in a high availability zone with two instances, and it includes a scheduled task. Since there are two containers, I’d like to ensure that they don’t execute the task at the same time. I’m addressing this by assigning a system variable. I changed the value in one of the containers via the console, but this undermines the automation of the process.

I see. Environment variables aren't going to be a great solution since they need to be identical to every container instance that is running. Cycle treats all instances of a container as identical, and the environment variables are applied the same way. If you want two different instances to execute a scheduled task at different times, I can think of two solutions:

• Create two different containers of the same image, and use the environment variable approach. This is probably the simplest and most straight forward
• If for some reason they can't be separate containers and MUST be part of the same one, then I would move the scheduling task to its own container that executes independently of the container with multiple instances. I'm not sure exactly what your container task is doing, so this may or may not be a good solution depending on what needs to happen.

Hope that helps clear things up!

Thank you! These are exactly the options I was considering, but I had to ask since, for example, such functionality exists in Kubernetes.

Hey Ruslan,

It looks like you were able to get an answer that will solve the question, but if you're willing I'd love to know more about this scheduled process and what it does.

1. Does it need to run on every instance of the container?
2. What type of job is it completing?
3. Is the work its doing heavy on the process or some database? (what prevents it from running in parallel?)

Hi Christopher! Currently, this is a very simple service that monitors application operation with a 5-minute interval. Since the decision has been made to improve system reliability as much as possible, the application is deployed in two regions.

It executes a cron job every 10 minutes. However, if there are two instances, the tasks will run at the same time. Based on the value of a system variable:

The first instance works at 0, 10, 20, 30... The second instance works at 5, 15, 25... This creates an alternating 5-minute interval for execution. That’s why I was curious about the possibility of modifying their behavior using environment variables.

Since this is a simple service, I just changed the variable value manually through the SSH console. It’s not critical. I was just curious because I know Kubernetes allows for such configurations, which is why I asked.

There are other cases in an application currently being prepared for migration. In that case, I’ll likely follow your advice and move the cron processes to a separate container.

Thanks for clarifying. I'm still a bit unclear on why exactly it would matter if both instances were to run this operation at the same time. Is there some type of locked resource they would have to operate on or, what am I missing there?

There’s no particular reason; I’m just a bit of a perfectionist. Instead of having both instances run simultaneously every 5 minutes, I prefer them to work alternately, with each running every 10 minutes but offset by 5 minutes from each other.

What would be the desired pattern if you were to scale to 5, 10, or 100 instances?

Hi Christopher!

It would be ideal if, in addition to assigning a tag, we could also assign a tag mask for Container Identifiers.

Additionally, it would be helpful to have the ability to structure Scoped Variables into folders or filter them by tag, name, or something similar. Sometimes, it’s more convenient to see only the variables related to a specific container rather than all of them.

Hey Ruslan,

This is on the roadmap with a hopeful target of Q1/Q2 of next year.

However, re: Sometimes, it’s more convenient to see only the variables related to a specific container rather than all of them. I'm not sure if you saw in a recent release but each container's dashboard now shows all associated variables.

I second the ability to add by tag, that would be solid.

As for the see only variables related to this container, this feature is out and it's been an awesome addition for quick security checks or debugging containers.