https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# aws
s
This message was deleted.
b
You could use stack outputs and references to access it rather than trying to get it as you have described. Stack outputs: https://www.pulumi.com/docs/intro/concepts/stack/#outputs Stack references: https://www.pulumi.com/docs/intro/concepts/stack/#stackreferences
s
yeah, I am using this approach to get the 
vpcId
from the other stack. But 
new awsx.ecs.Cluster
require the whole vpc object to be passed that why I am trying to retrieve the vpc using the id
b
If you use the newer version of AWSX (https://www.pulumi.com/registry/packages/awsx/api-docs/) you’ll see that we’ve actually got rid of the cluster resource because it wasn’t adding any value over the base AWS Provider ECS cluster resource. This way you can still create task definitions and services using AWSX but you’ll just need the VPC Id instead of the VPC object
Caveat - if you update the package and are still using the pre-v1 version, you’ll need to use the 
classic
module - see the readme details here: https://github.com/pulumi/pulumi-awsx#migration-from-0x-to-10
s
makes sense, so the best solution here is to use`aws.ec2.getVpc()` with 
new aws.ecs.Cluster
instead of 
awsx
right?
b
no, you don’t even need the vpc id with the 
aws.ecs.Cluster
. You use it for the service later on
s
yeah, it needs to be added to the task definition
Copy code
networkConfiguration: {
        subnets: vpc.privateSubnetIds,
        securityGroups: [securityGroup.id],
    },
b
Ah I see. Then I’d add 
vpc.privateSubnetIds
to the stack outputs as well
so you can access via stack references
s
yeah and use it inside 
awsx.ecs.FargateService
b
yes
s
thanks a lot!
it was great having a solution for that
so do you think I should get rid of AWSX?
as in my previous code I was creating VPCs and cluster using it. I believe I should migrate the code
b
It’s great for setting up VPCs as it takes away a lot of the pain setting up things like route tables, nat gateways etc.
And it does have strongly typed 
containerdefinitions
for the task definitions (so you don’t have to just have json you pass in)
So there are benefits
s
ok, so I should only consider to keep it for VPCs only. As I am afraid if more functions were removed in the future
I have another question which I am not sure about: If I migrate the old code for the cluster from AWSX to AWS, will Pulumi recognize that it’s the same resource or will it destroy and create a new resource?
also, I believe there is something wrong in the documentation cluster arg should be of type 
cluster?: Cluster;
not as mentioned in the documentation:
Copy code
const service = new awsx.ecs.FargateService("service", {
    cluster: cluster.arn,
    assignPublicIp: true,
    desiredCount: 2,
    taskDefinitionArgs: {
        container: {
            image: "nginx:latest",
            cpu: 512,
            memory: 128,
            essential: true,
            portMappings: [{
                targetGroup: lb.defaultTargetGroup,
            }],
        },
    },
});
also I needed to pass 
subnets:[]
directly to the fargate service not as mentioned here:
Copy code
networkConfiguration: {
  subnets: vpc.privateSubnetIds,
  securityGroups: [securityGroup.id],
},
b
I have another question which I am not sure about: If I migrate the old code for the cluster from AWSX to AWS, will Pulumi recognize that it’s the same resource or will it destroy and create a new resource?
No, you’ll need to re-import into your state. Since they’re already there, you already have a list of resources and the IDs, but it will need a bit of work your end. It’s not difficult but might be a bit time consuming. Guide to importing: https://www.pulumi.com/docs/guides/adopting/import/
s
Thanks! this was very helpful.
6 Views
Open in Slack
PreviousNext
Powered by