Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
package-authoring
pulumi-ai
pulumi-cdk
pulumi-cloud
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Title
c
cuddly-carpenter-20638
04/30/2021, 12:36 AMIs 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
little-cartoon-10569
04/30/2021, 12:37 AMNo. You have to log in, but you can log into any backend, it doesn't have to be the Pulumi one.
c
cuddly-carpenter-20638
04/30/2021, 12:37 AMAh, got it.
So, it would be similar to how I’m currently playing around with pulumi locally.
l
little-cartoon-10569
04/30/2021, 12:38 AMExactly.
On that page, the sample setup.sh has a line
pulumi loginc
cuddly-carpenter-20638
04/30/2021, 12:39 AMGot 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
little-cartoon-10569
04/30/2021, 12:42 AMI 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
cuddly-carpenter-20638
04/30/2021, 12:47 AMInteresting! 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.
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/configSomething like that.
l
little-cartoon-10569
04/30/2021, 12:51 AMThere 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
cuddly-carpenter-20638
04/30/2021, 12:55 AMAwesome, 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