This message was deleted.
# platform-stories
s
This message was deleted.
j
Hey @DanK, thanks for sharing! I will bookmark this and link people to it instead of giving ad-hoc history lessons in the future! I like the level of detail and language used for techy people but think it might too ahrd to read for non-techies. Stumbled over two strange typos but otherwise an easy read for me 🙂 PS: Curious how what I assume must have been "grasp" became "grok" :D
a
Hey, that's very cool and reads easily! Not sure about how would that work and what your expectation is: 🙂
The biggest drawback I noticed when the first Terraform was released was the inability to (elegantly) access systems via the shell.
do you mean that you'd like Terraform to provide e.g. a wrapper around the AWS CLI, so that you can list AWS resources using Terraform? or do you mean that you'd like to ssh login into virtual machines or containers? what would be the goal here? 🙂
d
Thanks for the feedback! Do we like the word https://www.merriam-webster.com/dictionary/grok ? 😄
@Ava Czechowska I meant after provisioning a system, logging into it to perform setup work. I realize this can be done using user-data scripts and/or utilizing an AMI build process with CI. Sometimes we need to access the system/s in to configure them once they are live and online - like in a cluster membership or other complex orchestration. And we CAN do this with the terrform shell module... but it's just not that elegant - Ansible is better for that imo.
a
Ok. Have you tried the Terraform null_resource? You can use it to run Ansible or a bash script or any other script to run inside of a vm. I haven't work with the terraform shell module, it seems that both of them do the same/similar thing
Or you could also get Terraform to generate some Outputs (e.g. an IP of the vm to be provisioned), so that you can later log into that vm
But I understand the struggle for elegance 🙂
d
That is cool, good to know, thanks! I think it would run a "standalone" playbook which would not necessarily be part of a wider cluster/orchestration system. Which is totally fine for most applications depending on how they are designed. I've run into a some dynamic cluster configuration requirements which really benefited from a central controller orchestrating n systems to do different things based on different states.