Since the resource_class is defined at the top level, vs. per container, If I use a large / xlarge / whatever resource class for a docker run that has one or more accessory containers, will the accessory / secondary containers also be larger in size, and will that increase the number of credits used by that amount?
Hi, can you give an example of your configuration and what you are aiming for?
The resource_class key can be used at the job level directly or via defined Executors, so allowing each job to be sized differently. So much of the granularity of control you have comes from the way the script is structured.
1 Like
So imagine a config like this:
executors:
docker:
- image: cimg/node:16.19
environment:
DATABASE_URL: postgresql://pguser:pguser@localhost:5432/foo
REDIS_HOST: localhost
REDIS_PORT: 6379
- image: redis:5-alpine
- image: postgres:14-alpine
environment:
POSTGRES_DB: foo
POSTGRES_PASSWORD: pguser
POSTGRES_USER: pguser
resource_class: xlarge
My question is just whether the accessory containers (the redis and postgresql ones, in this example) follow the executor’s resource_class, and if so, if there’s a way to suppress that (especially if it’s billed that way) - otherwise, if you only needed the accessory containers to be “small” or “medium”, making a job like this, say, xlarge could be quite expensive.
As I understand things
-
the first image you detail is the primary container/environment which becomes the base environment that the circleci script is run in and so where any shell commands/scripts are run.
-
any additional images listed cause another docker container to start up on the same environment. These images then have any exposed ports published on localhost so that you can communicate with them.
So when you use “resource_class: xlarge” you are creating a single chargeable system on which all the defined images are loaded. Rather than a number of independent systems, each running one image.
2 Likes