I am using a jinja2 template for creating several files. Those differ a bit dependent on a set variable.

Here's the code:

{% if production_env == "prod" or "stage" %}
  password: "{{ group_token }}"
  username: usernamedoesntmatterhere
{% elif production_env == "dev" %}
  password: "{{ mytoken }}"
  username: "{{ mytokenname }}"
{% else %}
    NONE
{% endif %}

As you can see when production_env is set to dev it should template the second block. It seems that my elif condition is not working anymore. I used a debug task to get output which variable is set and this is correctly set to dev Ansible renders the first block even if dev is set correctly.

That worked fine for months, not sure why it doesn't now.

I already ditched the elif block and set it to else, even this is not working.

Any hints?

Thanks

No there is no way to tell Terraform to skip creating a resource if it already exists.

Is there a reason why you want to skip resource creation? Why not import the existing resource into Terraform state file so it doesn't try to create the resource that already exists?

You could provide more background information for this.

I've got a private github actions runner with a repo that contains a helm chart for logstash

runner@runnerdeploy-elkstack-6pkp9-45kpw:
/runner/_work/elastic-logstash-kibana/elastic-logstash-kibana/elkhelmconfig/logstash$ ls
    Chart.yaml  templates  values.yaml

The values.yaml is in elkhelmconfig/logstash

so manually I would go to the elkhelmconfig directory and run

helm install logstash logstash/

but how to do it from within the private runner automatically? There is no k8s config and the helm action fails on aws-cli not installed.

Can it be done scripted by curl https://***helm && chmod a+x helm && helm upgrade logstash

or something?

we have two independent kubernetes clusters that work like Main and it's high available one. and we have some stateful applications that store data within cluster's persistent volumes. my question is .. can I share a PV between those two clusters, so I can have a final result of two pods running on the two clusters reading/writing on the same volume as if they're running on one same cluster. I'm focusing on sharing data between the pods regardless how the pods would handle the data writing.

This question is not in case of kubernetes but when you use servers or docker for deployment using CICD tool like Jenkins or gitlab. In jenkins or gitlab I've agents/runners and in pipeline stages I've a deploy stage. Now, where should this deployment ideally happen? On the agent? or or some other server (through ssh)?

Using https://kustomize.io/ you can combine multiple helm charts and make tweaks to them on the fly. https://jfrog.com/blog/power-up-helm-charts-using-kustomize-to-manage-kubernetes-deployments/ for doing this sort of thing.

I'm not sure if it's the right place to ask this question. So let me know, if it's not.

I'm building a front end app with VueJs. I actually use 2 computer. I use the first computer as a "server" (just a computer that is always on) and and the other one I use it to code.

The server have a VSCode that is always open that always run my front end app. I use Remote Desktop Connection to connect to this server when I need to code/build/run. I use Azure Dev Ops as a Git solution.

But all this setup is not the best way to work. It's kinda annoying to connect to the server and let vscode always open.

What I want to know is : Is it possible to create a better dev. environnement? For example, what I want to do is to be able to work from VSCode on my "dev's computer" and whenever I push something in Azure DevOps, my server re-build and re-run my app.

How should I start ? Can you give me any documentation to help me? I couldn't find anything in the net (maybe because I'm doing something wrong in my research)

The referenced question deals with docker containers being attached to both a bridge and the host network at the same time.

However, to expose a service, you publish your service typically via dockers ingress rather than host most networking so this is rarely an issue.

i.e. the following compose fragment is legal:

services:
  my-api:
    image: foo
    networks:
    - overlay1
    - bridge1
    ports:
    - 9090:8080

Wheras this fragment is illegal:

services:
  my-api:
    image: foo
    # docker compose host mode networking.
    network_mode: host
    networks:
    - overlay1
    - bridge1
    - hostent
    ports:
    # docker swarm can publish a port on a host. This should work
    - target: 80
      published: 8080
      protocol: tcp
      mode: host
networks:
A different swarm compatible take on --net:host
Also can't be mixed with ingress networking.
hostnet:

external: true

name: host

I am trying to use terraform to spin up a new instance of a server.

Using the AWS provider , I get this error:

╷
│ Warning: Resource targeting is in effect
│ 
│ You are creating a plan with the -target option, which means that the result of this plan may not represent all of the changes requested by the current configuration.
│ 
│ The -target option is not for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it as part of an
│ error message.
╵
╷
│ Error: error configuring Terraform AWS Provider: failed to get shared config profile, 2auth
│ 
│   with provider["registry.terraform.io/hashicorp/aws"],
│   on main.tf line 1, in provider "aws":
│    1: provider "aws" {
│ 

first off , I have no idea where this 2auth profile it is referencing is.

Also I have tried setting my credentials with in both the tf file

provider "aws" {
   region = var.aws_region
   shared_credentials_file = "/Users/samueldare/.aws/credentials"
}

and as environment variables, but it still doesnt work.

I would appreciate pointers as to what I am doing wrong.

I'm trying to deploy a docker image to Azure Container Registry via an Azure Devops pipeline. Now this works fine when I run it with this script:

trigger:
- master
variables:
Container registry service connection established during pipeline creation
dockerRegistryServiceConnection: 'some_id'

imageRepository: 'worker'

containerRegistry: 'microcontainerapptest.azurecr.io'

dockerfilePath: '$(Build.SourcesDirectory)/Dockerfile'

tag: '$(Build.BuildId)'
Agent VM image name
vmImageName: 'ubuntu-latest'
stages:

stage: Build

displayName: Build and push stage

jobs:

job: Build

displayName: Build

pool:

vmImage: $(vmImageName)

steps:

task: Docker@2

displayName: Build and push an image to container registry

inputs:

command: buildAndPush

repository: $(imageRepository)

dockerfile: $(dockerfilePath)

containerRegistry: $(dockerRegistryServiceConnection)

tags: |

$(tag)

However, I want to actually use a deployment job so I can run the pipeline in different environments. Therefore I updated the .yml like this:

trigger:
- master
variables:
Container registry service connection established during pipeline creation
dockerRegistryServiceConnection: 'some_id'

imageRepository: 'worker'

containerRegistry: 'microcontainerapptest.azurecr.io'

dockerfilePath: '$(Build.SourcesDirectory)/Dockerfile'

tag: '$(Build.BuildId)'
Agent VM image name
vmImageName: 'ubuntu-latest'
stages:

stage: Build

displayName: Build and push stage

jobs:

deployment:

displayName: Build docker image

environment: $(DEPLOY_ENVIRONMENT)

strategy:

runOnce:

deploy:

steps:

- task: Docker@2

displayName: Build and push an image to container registry

inputs:

command: buildAndPush

repository: $(imageRepository)

dockerfile: $(Build.SourcesDirectory)/Dockerfile

containerRegistry: $(dockerRegistryServiceConnection)

tags: |

$(tag)

Making a deployment job out of this. Now when I run the pipeline like this I get an error

Unhandled: No Dockerfile matching /home/vsts/work/1/s/Dockerfile was found.

So it seems like the dockerfilePath is not valid anymore when I run it as a deployment job. I have searched but don't have a clue as to why this would be the case, does anybody know the answer to this?