Friends,
I am running a RabbitMQ container in K8S. When I ran it for the first time I created a simple password and a username, which I want to change now but I just can't somehow. I've changed the values here but they aren't being overwritten:
env:
- name: "RABBITMQ_DEFAULT_USER"
value: "Z3Vlc3Q="
- name: "RABBITMQ_DEFAULT_PASS"
value: "Z3Vlc3Q="
When I open the UI I still have to log in with the old credentials. Any idea how can I update them?
Related
In the last couple of weeks I moved from clicking pihole in portainer to using stacks / docker-compose.yaml
However, this also limited the functionality of my pihole. At some point it was no longer possible to perform the gravity update via the web interface of the pihole. For this I always had to go to the console of the pihole and run
pihole -g
Also manually added black and whitelist entries were only taken into account after a manual update. The deactivation of the pihole in the web interface did not work anymore.
I was able to fix this by removing the following entries in my docker-compose file:
environment:
PIHOLE_DNS_: 9.9.9.9#53;9.9.9.9#53
DNS1: 9.9.9.9 # Quad9 (filtered, DNSSEC)
DNS2: 9.9.9.9 # If we don't specify two, it will auto pick google.
security_opt:
- no-new-privileges:true
cap_add:
- NET_ADMIN
dns:
- 127.0.0.1
- 9.9.9.9
The config lead to 9.9.9.9 in custom1 upstream DNS server. Currently I clicked the upstream server (on the left in settings) manually. Which of the DNS entry do I have to reuse and why does the pihole think its a custom and not one of the standard dns entries?
Are these settings stored in one of the volumes? I could not find any entries in Portainer environment variables when I removed them explicitly.
We are using Ansistrano Deploy
roles:
- role: ansistrano.deploy
We want to be able to detect when the deploy fails for any reason (or succeeds), so we can send a Slack notification.
How can we get a return code or similar on this to know the result of the deploy?
Not being familiar under the hood with Ansistrano and more specifically with the error handling already in place inside the role, I'm not entirely sure this will work out of the box.
But my first natural attempt would be to use a block with error handling. This will require to change the way you call the role to use import_role instead of the play-level role: keyword.
Here is a pseudo playbook example to give you the global idea:
- hosts: my_deploy_hosts
tasks:
- name: deploy my_app with some error control
block:
- name: run the ansistrano deploy role
import_role:
name: ansistrano.deploy
- name: If we got there, above ran successfully
debug:
msg: "You should send a ++ message to slack"
rescue:
- name: If we get into this something went wrong
debug:
msg: "Houston. Houston. We have a problem."
We currently use Codeship Pro to push Docker images to a private registry on AWS, as well as to deploy those images to an ECS cluster.
However, the codeship-steps.yml file includes a hard-coded region name for which AWS region I'm pushing to. For example:
- name: push_production
service: app
type: push
image_name: 123456789012.dkr.ecr.us-east-1.amazonaws.com/project/app-name
image_tag: "{{.Timestamp}}"
tag: master
registry: https://123456789012.dkr.ecr.us-east-1.amazonaws.com
dockercfg_service: aws_generator
I would like to be able to fairly easily switch this to deploy to a different AWS region. Thus the question:
Is it possible to use variables in a codeship-steps.yml file?
I know some of the properties can use a handful of built-in variables provided by Codeship (such as the {{.Timestamp}} value used for the image_tag property), but I don't know if, for example, values from an env_file can be used in the image_name, registry, and/or command properties of a step.
I'm imagining something like this...
codeship-steps.yml:
- name: push_production
service: app
type: push
image_name: "123456789012.dkr.ecr.{{.AWS_REGION}}.amazonaws.com/project/app-name"
image_tag: "{{.Timestamp}}"
tag: master
registry: "https://123456789012.dkr.ecr.{{.AWS_REGION}}.amazonaws.com"
dockercfg_service: aws_generator
... but that results in an "error parsing image name during push step: invalid reference format" on the push step.
I've tried simply not specifying the registry in the image_name...
image_name: project/app-name
... but I get a "Build Error: no basic auth credentials" on the push step. At this point, I'm running out of ideas.
Is it possible to use [environment] variables in a codeship-steps.yml file?
While the image_tag can take advantage of Go templates, the same is not the case for image_name, registry, or anything else. This is a separate set of templating variables that are accessible only to the image_tag generation.
As for environment variables in general (CI environment variables or those defined in the service configs), these values can be used in codeship-steps.yml on the command step when passed through a shell command. For example:
- service: app
command: echo The branch name is: $CI_BRANCH
Results in:
The branch name is: $CI_BRANCH
- service: app
command: /bin/sh -c 'echo The branch name is: $CI_BRANCH'
Results in:
The branch name is: master
As for your 'no basic auth credentials' error message, it's possible that there's an issue with how you are retrieving the basic auth credentials for access to your image registry. If you are on a MacOS device, I would recommend that you review our documentation on how to generate Docker credentials.
I have a repository that build and deploys two different components - a frontend and a backend. Each of these have a specific set of steps that need to be executed for the CICD. Is there a way to run a selective set of steps based on which component has actually changed. For e.g. let us say all my frontend is under frontend/ and all my backend is under backend/. Is there a way to run a selective set of steps when there are changes only in the frontend ?
The closest approach would be to adopt branch naming conventions that separate frontend and backend test builds.
For example, you could manage all frontend work with a frontend- prefix and all backend work with a backend- prefix. The codeship-steps.yml would then be implemented as:
- name: Frontend tests
service: your-app
type: serial
tag: ^frontend-
steps:
- service: your-app
command: ./run-frontend-test.sh
- [other step commands...]
- name: Backend tests
service: your-app
type: serial
tag: ^backend-
steps:
- service: your-app
command: ./run-backend-test.sh
- [other step commands...]
See here for more.
I'm trying to set up a local drone.io server for CD with my github account. I'm using the official docker container. The setup instructions says to add an application in github settings to get the client id and secret needed for drone github remote configuration, which I have done, the only difference from official docs is that I see the "Register new application" on the "Developer Applications" and not on "Authorized Applications", I hope it's the same. Then, I have defined the environment variables:
REMOTE_DRIVER=github
REMOTE_CONFIG=https://github.com?client_id=${client_id}&client_secret=${client_secret}
Replacing the client id and secret with my own. Then I bring the container up and try to login, I get redirected to github's authorization page, I authorize it and when redirected back I get this error:
Unable to login. Registration is closed.
And the redirected URL is:
http://drone.myserver.com/login?error=access_denied
I really don't have a clue on what could possible be missing/misconfigured, the same setup works with the bitbucket remote.
Found the problem. Browsing drone issues I found this one that mentions that I need to add open=true to the query string so drone is able to create the github application.
If you get access_denied in web drone
This is docker-compose and answer -> DRONE_OPEN=true:
version: '2'
services:
drone-server:
image: drone/drone:0.7
ports:
- 80:8000
volumes:
- ./drone:/var/lib/drone/
restart: always
environment:
- DRONE_GITLAB=true
- DRONE_GITLAB_CLIENT=change_value
- DRONE_GITLAB_SECRET=change_value
- DRONE_GITLAB_URL=https://gitlab-01example.com
- DRONE_SECRET=change_value
- DRONE_GITLAB_SKIP_VERIFY=true
- DRONE_DEBUG=true
- DRONE_OPEN=true
drone-agent:
image: drone/drone:0.7
command: agent
restart: always
depends_on:
- drone-server
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- DRONE_SERVER=ws://drone-server:8000/ws/broker
- DRONE_SECRET=change_value
- DRONE_GITLAB_SKIP_VERIFY=true