This issue <https://github.com/pulumi/pulumi-cloud...
# general
f
This issue https://github.com/pulumi/pulumi-cloud/issues/627 is currently blocking me. I need to be able to set a Docker build arg from the output of another Pulumi resource. Is there a workaround for this?
w
cc @lemon-spoon-91807 in case he has ideas.
l
ok. i looked into this, and there's def a problem going down this route.
the major issue is that we use the build-args to generate the name of the ECR repository we're going to create
which means that we now don't know hte name of the repo because the name itself is dependent on data which is now an output.
f
Why are the build args used to create the ECR repo?
l
to ensure we give a unique name to place this image at
so there's no 'easy' fix here where i could just allow for htis and have it pushed into the next release.
f
Actually, I think I could use an ENV instead of ARG here. I don't mind the arg being exposed at runtime.
l
@white-balloon-205 any ideas here for something obvious i'm missing?
we baked htis pretty deep. but maybe there's some other way of producing the ecr repo name that we could use instead?
f
Are container
environment
variables available when the container is built?
For example,
Copy code
let nginxFargateService = new infra.x.ecs.FargateService("nginx", {
    cluster: cluster,
    taskDefinitionArgs: {
        containers: {
            nginx: {
                image: infra.x.ecs.Image.fromDockerBuild({
                    cacheFrom: true,
                    context: "./nginx",
                }),
                portMappings: nginxLoadBalancer,
                memory: 256,
                environment: [{
                    name: "FOO",
                    value: "foo"
                }]
            }
        }
    },
    desiredCount: 1
});
Is
FOO
available when building the container?
l
"available" in what sense?
f
I can use the value of
FOO
in my Dockerfile.
l
they are baked intot he containerDefinitions portion of the TaskDefinition resource that is created.
f
Does that make them available when building the container?
l
when building, i don't think so no. for things like docker's ENTRYPOINT they should be avialable
it somewhat depends on what you mean by 'building'. which parts of the dockerfile would need this?
f
I am using the value of the var to generate an nginx config.
l
could you clarify your use case a bit more? maybe we can step back a moment and discuss what you're trying to accomplish here.
and nginx needs this information at build time?
it cannot use the data when it launches by reading something out of hte environment?
f
Ideally. There may be a way to get it at runtime. There may be some perf tradeoffs from pulling from an env var.
For example,
Copy code
events {
    worker_connections 1024;
}

http {
    server {
        listen 443;
        ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
        ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

        location /api {
            proxy_pass {{api_url}};
            proxy_ssl_server_name on;
            proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        }

        location / {
            proxy_pass {{frontend_url}};
            proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        }
    }
}
I need to fill in
{{api_url}}
and
{{frontend_url}}
with the values generated from Pulumi resources.
This is currently how I am doing it:
Copy code
ARG API_URL
ARG FRONTEND_URL
RUN sed -i "s,{{api_url}},"$API_URL",g" /etc/nginx/nginx.conf
RUN sed -i "s,{{frontend_url}},"$FRONTEND_URL",g" /etc/nginx/nginx.conf
l
does RUN happen at build time? or is it used to define what will happen at runtime when the container actually launches?
f
Build time. I suppose I could make a script that runs at container startup.
l
it looks like it happens at build time AFAICT. but i'm no expert
also, i'm not opposed to having 'build args' be something that could be the result of a previous resource. it just means though that we need some sort of answer about how we can name these repositories.
i.e. if we allowed build-args to be computed inputs, then the client (i.e. you, would likely have to supply a name for the repo that htey wanted to use)
f
Right - I think it makes sense.
l
since we could no longer do that on your behalf
f
That seems fine to me.
l
let me chat with @white-balloon-205 about this.
👌 1
f
I can't use `Output`s in
environment
.