nginx-ingress와 namespace nginx-ingress는 기본적으로 모든 namespace의 resource를 control할 수 있도록 배포가 되어진다. 해당 개념과는 다르게 지정된 namespace의 resource만을 control할수 있게도 가능하다. 이번에는 지정된 namespace의 resource만 control 되는 환경에서 다른 namespace에 있는 service를 backend로 가지는 ingress를 생성하는 방법에 대하여 알아보도록 하겠다. 참고로 아래 링크에 namespace를 지정하는 방식에 대한 설명이 있으니 한번 참고해 보면 좋을듯하다. https://docs.nginx.com/nginx-ingress-controller/installation/running..
Github plugin Jenkins pipeline job의 경우 기본 github plugin으로는 job 실행이 되지 않는다. https://plugins.jenkins.io/github/ 물론 우회할수 있는 방법이 있긴하다. 우회방법은 아래와 같다. freestyle job을 생성 (해당 job은 build other projects를 post-build actions으로 지정)하고 아래 trigger 설정을 추가한다. projects to build에 지정된 job에 pipeline 선언 (사전에 pipeline Job은 생성되어 있다는 가정) 이후 github에 설정을 추가한다. 요약하자면 두개의 job을 생성한다. 하나는 freestyle job, 나머지는 pipeline job으로 생성하..
workspace workspace의 경우 기본적으로 아래 경로에 저장되게 된다. /var/jenkins_home/jobs/github-freestyle-webhook/builds/2/archive 실제 Jenkins workspace에서 파일 경로를 확인해보면 다음과 같은 경로를 가진다. https://jenkins.example.com/job/job-name/lastSuccessfulBuild/artifact/README.md 실제 jenkins 경로에서 확인해보면 정확히 매칭되는 경로를 찾을수는 없고 builds 내에 permalinks라는 파일이 존재하고 해당 파일내에 마지막 성공한 빌드 정보가 기록되어 있고 해당 number에 맞는 경로를 찾아가게 된다. jenkins@jenkins-cdf944..
아래와 같은 경로로 이동하여 log recorder를 생성하자. 다음과 같은 log record가 생성되어 확인이 가능하다. 실제 당시 문제는 위 이미지 상에 나와있듯이 "Skipped github-integration-test because it doesn't have a matching repository" 메세지를 통해 확인이 가능했다. 예시 github plugin을 예를 들어 사용해보자. 먼저 github plugin이 소개된 페이지에서 보면 다음과 같이 logging에 대한 class name을 제공하고 있다. 위에 확인된 class name을 아래 설정에 추가해놓자. 이후 log records에 생성한 github log 에서 확인해보면 위와 같은 log가 github webhook이 발생될..
certbot을 이용한 무료 certification 생성하여 적용하는 과정에 대해 알아보자. 해당 내용은 아래와 같은 환경이 마련된 상태에서 진행되었다. kubernetes AWS route53 dns 등록 : example.com(가정사항) nginx-ingress : abc.example.com 실제 동작될 환경은 kubernetes 상에 동작되는 pod이며 해당 pod는 ingress로 외부에서 연결이 가능하다. ingress의 tls 항목에 secretName에서 사용할 인증서를 아래와 같은 과정을 통해 생성 및 적용해보자. certbot 준비 CentOS7 기준으로 아래와 같은 순서로 인증서 생성을 진행한다. yum install epel-release -y yum install certbot..
Kubernetes 환경에서 Logging 및 Monitoring을 위한 환경 구성에 대하여 알아보도록 하자. 먼저 사용되는 구성요소들은 다음과 같다. logging Fluent-bit (각 노드) -> elasticsearch -> grafana / kibana monitoring node_exporter (각 노드) -> prometheus -> grafana 각 구성요소는 다음과 같은 구성으로 이루어진다. component helm chart namspace persistence volume etc ElasticSearch elastic/elasticsearch(helm.elastic.co) LMA 사용 Fluentbit stable/fluent-bit LMA 미사용 elasticsearch로 lo..
매번 까먹어서 통신을 위한 domain 을 입력해야할때 몇번을 찾는 경우가 있어 이번 기회에 정리하고자 한다. [service-name].[namespace].svc.[cluster-name] 일반적으로 아래와 같이 kubernetes로 구동시켜진 pod에 exec 로 들어가 확인해보면 cluster name과 함께 service-name을 제외한 도메인을 확인할수 있다. [root@master001 ~]# kubectl exec -it jenkins-859966c5fb-cczrk -n jenkins cat /etc/resolv.conf nameserver 10.233.0.3 search jenkins.svc.cluster.local svc.cluster.local cluster.local options..
helm을 신규로 만들게 되면 helm chart repo를 개인적으로 소유해야 하는 경우가 발생되기도 한다. 이러한 경우 어떻게 repo를 만들어서 추가하여 사용할 수 있는지 알아보도록 하자. helm chart repo on localhost 우선 helm chart를 localhost에서 구동해보자. 물론 chart museum이나 minio(s3)같은 환경을 활용해도 무방하다. 여기서는 간단히 동작을 알아보기 위해 간단히 python webserver로 동작시키는 방식을 사용했다. 우선 여러개의 helm chart가 존재하는 디렉토리로 이동해 다음과 같은 helm chart repo로 동작되게 하기 위한 준비과정을 수행한다. python http.server 모듈을 이용한 웹서버 구동 jacob@..
- Total
- Today
- Yesterday
- metallb
- socket
- kata container
- wsl2
- Terraform
- Helm Chart
- DevSecOps
- boundary ssh
- OpenStack
- minikube
- nginx-ingress
- ceph
- hashicorp boundary
- macvlan
- kubernetes install
- Jenkinsfile
- crashloopbackoff
- kubernetes
- open policy agent
- ansible
- jenkins
- GateKeeper
- mattermost
- aquasecurity
- openstack backup
- K3S
- openstacksdk
- vmware openstack
- minio
- azure policy
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |