https://pulumi.com logo
Join Slack
Powered by
Is it required to register on <app.pulumi.com> eve...
# general
c
Is it required to register on app.pulumi.com even if we’re using it in our self-hosted GitLab instance, for CI/CD? .https://www.pulumi.com/docs/guides/continuous-delivery/gitlab-ci/
l
No. You have to log in, but you can log into any backend, it doesn't have to be the Pulumi one.
c
Ah, got it.
So, it would be similar to how I’m currently playing around with pulumi locally.
l
Exactly.
On that page, the sample setup.sh has a line 
pulumi login
. You would need a different line there, to log into the correct backend.
c
Got it.
Regarding the _stacks_: ideally the stack config would reside in the same repo as the app/service I’m trying to deploy. Is it also possible to have that config elsewhere (say in s3/some other repo), that I can just wget in my service CI at deployment time and configure and use?
l
I suppose so, so long as you get it before you run any pulumi commands..
Sounds like you might want to investigate automation-api. That doesn't require the stack to be on disc at all, you can configure it programmatically.
c
Interesting! I’ll check it out. What I’m thinking of is if I want to create, say, a generic k8s deployer based on pulumi, that I can wire up in the Gitlab CI of any service, and use some sort of config hosted in the service repo to figure out what’s the image name, resources etc, the pulumi code could do the rest. I guess what I’m trying to get at is taking the headache of having to manage the infra/deploy part away from developers. They can just work on their apps, create a small config file that defines what k8s resources the app needs, what svc/ing to configure, and the rest can be handled by this utility that could just be packaged as a docker image and referenced in the Gitlab CI.
Copy code
deploy:
  extends: .aws_auth  ## takes care of aws auth etc.
  image: my-co/my-pulumi-image
  stage: deploy
  script:
    - node my-pulumi-app /path/to/config
Something like that.
l
There are ways to achieve that, and more (and simpler) ways coming in the future. I would suggest for now going with template code, ComponentResources and the like, at least for the first few projects. This will allow the "early adopter" developers to learn more about Pulumi, while giving time for some in-progress Pulumi features to be completed and released.
Don't put too much effort into automating all the things right now. Much of it will be done for you, in the future.
c
Awesome, that is great to hear 🙂. Thanks for answering my totally noob questions, @little-cartoon-10569 🙏🏽. Pulumi looks really interesting. There’s so many use cases where we could reduce dev effort, keep things DRY, and avoid the massive YAML-fest we have right now. Looking forward to it.
👍 1
Open in Slack
PreviousNext
Powered by