https://pulumi.com logo
Powered by
#aws
Title
# aws
s

strong-helmet-83704

09/06/2022, 5:17 PM
I have some cloud resources which take a very long time to create or delete. For this reason it's best to leave these resources up between Pulumi up/down cycles. Currently I'm using the resource's tag:Name as an identifier to maintain persistence. I'm using the retain-on-delete and import_ resource options to either create a new resource or find one already created and re-use it.
Copy code
try:
        vgw = aws.ec2.get_vpn_gateway(
            filters=[aws.ec2.GetVpnGatewayFilterArgs(
                name="tag:Name",
                values=[f"Vgw"],
            )], opts=pulumi.ResourceOptions(provider=provider_options)
        )
        vgw = aws.ec2.VpnGateway(f"Vgw",
                tags={"Name": f"Vgw"},
                opts=pulumi.ResourceOptions(
                    provider=provider_options,
                    retain_on_delete=True,
                    import_=vgw.id
            )
        )
    except:
        vgw = aws.ec2.VpnGateway(f"Vgw",
            tags={"Name": f"Vgw"},
            opts=pulumi.ResourceOptions(
                provider=provider_options,
                retain_on_delete=True
            )
        )
Is this is the best way to achieve this? It works but it doesn't seem particularly elegant for such a common / simple task.
m

millions-furniture-75402

09/06/2022, 5:29 PM
s

strong-helmet-83704

09/06/2022, 5:33 PM
RetainOnDelete will keep the resource around but the stack state loses track after a destroy
Protect might be a good option, if it can also import a resource which already exists
v

victorious-church-57397

09/06/2022, 5:50 PM
I have used protect in conjunction with programatically importing resources and it works fine. we use it to manage some repositories in github đź‘Ť
âś… 1
Copy code
getRepository(jugoRepo).then((impRepo) => {
      // Import the repository
      const importedRepository = new github.Repository(
        `${jugoRepo.name}-repository`,
        {
          ...(impRepo as unknown as RepositoryArgs),
          defaultBranch: undefined,
          private: undefined,
          pages: undefined,
          deleteBranchOnMerge: true,
        },
        {
          protect: true,
          import: jugoRepo.name,
          ignoreChanges: ["vulnerabilityAlerts", "isTemplate"],
        }
      );
it can be a bit of a nightmare importing if the inputs/outputs dont match up
l

little-cartoon-10569

09/06/2022, 9:10 PM
In my opinion: no, this isn't the best way to handle this. I suggest moving these resources to a different project. I find that thinking of projects as groups of related resources which share a single deployment cycle is very helpful. If your current project needs two deployment cycles, then (in my opinion) it should be two projects.
đź‘Ť 1
g

great-sunset-355

09/07/2022, 8:03 AM
@little-cartoon-10569 I follow the same philosophy. How do you then handle these multi step deployments when you need to deploy multiple projects in a sequence? I mean programmatically? I'm thinking about using Azure Logic apps.
m

millions-furniture-75402

09/07/2022, 2:27 PM
We use a pattern for "base infrastructure" or "shared resources" for projects that have common for base resources that "child projects/stacks" will reference via the outputs of those projects using StackReferences.
In our case, these projects have their own explicit lifecycles, and we explicitly deploy the base, then the children
đź‘Ť 2
l

little-cartoon-10569

09/07/2022, 8:34 PM
Separate Pulumi projects are very easy to deploy in a fixed sequence at initial deployment: a short script can do it, or you can use automation-api to call out to the projects. In the simplest case of just calling one project then the other, with the same stack name in both, then I recommend the simple script: automation-api brings a lot more power, but that comes at the normal cost of additional complexity.
đź‘Ť 1
s

strong-helmet-83704

09/08/2022, 12:05 AM
@millions-furniture-75402 I’m tending toward this separation pattern also. But even then… reducing destroy/deploy timeframes and leaving alone “network” infrastructure / connections can be desirable
Powered by