https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# aws
s
This message was deleted.
l
The role is wrapped in an instance profile in the API/SDK, and Pulumi uses that. There's an 
iamInstanceProfile
parameter that takes the ID of the profile.
The domain join logic is not accessible through the API/SDK afaik. You can achieve the same thing through SSM, using the 
aws:domainJoin
document.
e
Hmm, I can't see that @little-cartoon-10569.
l
Search for "iamInstanceProfile"
e
iam_instance_profile - got it
👍 1
Thanks for the pointers - I'll read up on SSM
l
Good luck!
Actually it's a pretty long piece of code. Would you like to see my typescript that achieves it?
You need one document only, and one association per instance (unless you associate by tag or something else.. I do it by instance id).
e
Cheers @little-cartoon-10569 - that definitely helps. If I have multiple instances, can I just supply them in the InstanceIds value array, or do I need discrete associations? (apols - I'm at the limit of my knowledge with SSM)
l
IDs in the array works. Or you can tag them and associate with a filter that matches the tag. Have a look in the SSM ui: the SDK (and Pulumi) supports everything that the UI does.
👀 1
e
Cheers!
l
I use one association per instance, both in the instance's stack. That way when I destroy the instance (via its stack), the association can be easily destroyed. Don't need to worry about updating a shared association.
🙌 1
And the doc lives in a different project (shared resources, along with things like the VPN and Managed MicrosoftAD), and never gets destroyed.
e
OK, that makes sense. At the moment VPN, Managed AD, Subnets, SSM Doc, Associations, EC2 Instances etc are all in the one project. How easy is it to refactor these later?
l
Quite easy. Read up on StackReferences and imports. https://www.pulumi.com/docs/intro/concepts/stack/#stackreferences https://www.pulumi.com/docs/intro/concepts/resources/#import To migrate a resource from one project to another, you would import it into the new project (and move the code from the old project to the new one), then use 
pulumi state delete
to remove it from the old state. To use a resource in the new project but have it stay in the old project, you would use a StackReference.
e
Thanks @little-cartoon-10569. What's the python equivalent of your 
pulumi.all().apply()
call above? I have the folllowing:
Copy code
instance_startup_doc = aws.ssm.Document(
    f"{env}-{name}-ad-ec2-domain-join",
    document_type="Command",
    document_format="JSON",
    target_type="/AWS::EC2::Instance",
    content=json.dumps(
        {
            "schemaVersion": "2.2",
            "description": "Join a Windows machine to the domain",
            "parameters": {},
            "mainSteps": [
                {
                    "name": "joinDomain",
                    "action": "aws:domainJoin",
                    "inputs": {
                        "directoryId": managed_ad.id,
                        "directoryName": managed_ad.name,
                    },
                }
            ],
        }
    ),
    ...
)
... but pulumi up throws 
TypeError: Object of type Output is not JSON serializable
, presumably because the managed_ad props are not yet realised.
l
Yes, you'd want to call 
json.dumps()
inside an 
apply()
. Your link is to the theory. This link goes to the API specs:https://www.pulumi.com/docs/reference/pkg/python/pulumi/
e
Brill... ta
l
Looks like you want 
Output.all(managed_ad.id, managed_ad.name).apply()
. Very vague on how to pass a Callable into that though, sorry....
e
FWIW I was looking for that python doc in the Reference list on the left hand side and couldn't see it. I now see it's down the bottom of the API index page. Maybe a small UX doc improvement suggestion 🙂
l
Yes, they're working on the API specs right now, there's already been 2 or 3 improvements in the last few weeks.
e
🎉
l
And I really feel for C#, golang and Python users.. TS/JS layout isn't awesome but it's a lot better than the others...
e
Looks like Pulumi sets the associations up ok, but they're failing with this error: https://forums.aws.amazon.com/thread.jspa?messageID=966819
Assume this is AWS side to do with the aws:domainJoin action, but please do let me know if you've seen this before @little-cartoon-10569.
l
Haven't seen that before. Does it work sometimes and not other times? Looks like it might be adding an instance to the domain twice?
e
Yeah it fails reliably. Sadly the instance isn't actually added to the AD domain.
l
Maybe the bug is not only that it doesn't work, but also that the error message is wildly inaccurate. There's a few things to check when getting SSM working with EC2 instances. Odd ports need to be open. Same applies to getting them working with AD.
For SSM, you need 0.0.0.0/0:443 outbound and 0.0.0.0/0:1025-65535 open (or you can change 0.0.0.0/0 to the CIDR for SSM servers in your region, but they're provided by FQDN only, which makes SG/NACL filtering very awkward).
For AD, you need the opposite of the SG that was created for you by AWS when you created your Managed MicrosoftAD instance. If you are using your own instance, you need to figure out the ports yourself.
There's quite a lot of them.
e
Cool - I'll check those out. Know this isn't AWS support, so thanks for the pointers!
2 Views
Open in Slack
PreviousNext
Powered by