#Yobine

별생각 없이.. 테스트 용, spring boot 웹 어플리케이션 하나 만들었는데, pc 에 설치 된 tomcat 에서 실행이 안되어, 반나절을 이것 저것 해봤는데.. 절대, tomcat 문제도 아니고 spring 어플리케이션 내, 오류도 아니였다.

버전 문제였음.

1. spring boot 3.3.10
2. apache-tomcat-9.0.104-windows-x64 

별별 설정을 다 찾아 봤는데.. 마지막으로 혹시나 하는 마음에 ChatGPT 에게 물어보니.. ㅠㅠ...

💥 문제 원인: Spring Boot 3.x 는 Jakarta EE 10 기반, 하지만 Tomcat 9.x 는 Jakarta EE 8까지만 지원

✳️ Spring Boot 3.x → Jakarta EE 10 기반

Spring Boot 3.0부터는 기존 javax.* 패키지를 버리고 → jakarta.* 네임스페이스로 완전히 전환되었습니다.

❌ Tomcat 9.x → Jakarta EE 8까지만 지원

Tomcat 9.x는 javax.servlet.*, javax.el.*, javax.websocket.* 등 이전 네임스페이스 기반이고,
Spring Boot 3.x에서 생성된 WAR 파일을 실행하면 서블릿 API 호환 오류가 발생하거나
애플리케이션이 아예 실행되지 않는 경우가 발생합니다.

✅ 해결 방법 2가지

▶️ 방법 1: Tomcat 10.1+ 설치 (권장)

Tomcat 10.1부터 Jakarta EE 10을 공식 지원하므로 Spring Boot 3.x WAR 파일을 정상적으로 실행할 수 있습니다.

• Tomcat 10.1 다운로드
• 설치 후, 기존 ROOT.war 넣고 실행하면 바로 접속 가능해야 합니다.

Tomcat 10.0은 변환 브릿지 버전이라 10.1 이상을 추천드립니다.

▶️ 방법 2: Spring Boot 버전을 2.7.x로 다운그레이드 (비추천)

• Spring Boot 2.7.x는 javax.* 기반이므로 Tomcat 9.x에서 호환됩니다.
• 하지만 최신 기능과 보안 패치를 놓치게 되므로 권장하지 않아요.

📌 결론

Spring Boot 3.3.10 + Tomcat 9.x = ❌ 호환 불가
Spring Boot 3.3.10 + Tomcat 10.1.x = ✅ 정상 작동

나의 선택은 Tomcat upgrade..10.1 ... 업그레이드 하자마자.. hello 아흑..

참조: Slack notification 플러그인 - Slack Notification | Jenkins plugin

1. Jenkins 에 Slack 플러그인 설치
   1. Jenkins 서버에 이 플러그인을 설치
   2. Jenkins 홈페이지에서 Manage Jenkins로 이동.
      Manage Plugins으로 이동합.
   3. 탭을 Available로 변경.
   4. "slack"을 검색.
   5. 설치할 항목 옆의 체크박스를 선택 및 설치
2. Slack 내 App 생성 및 WorkGroup 에 설치
   1. 필요 시 Slack 계정을 생성: https://slack.com/
   2. https://api.slack.com/apps 로 이동하여 "Create New App"를 클릭
   3. "From an app manifest"를 클릭.
   4. 워크스페이스를 선택.
   5. Slack이 제공하는 예제 매니페스트를 삭제.
   6. "YAML"을 클릭.
   7. 다음 내용을 텍스트 상자에 복붙

   8. #bot 설정
      display_information:
        name: Jenkins
      features:
        bot_user:
          display_name: Jenkins사용자이름
          always_online: true
      oauth_config:
        scopes:
          bot:
            - channels:read
            - chat:write
            - chat:write.customize
            - files:write
            - reactions:write
            - users:read
            - users:read.email
            - groups:read
      settings:
        org_deploy_enabled: false
        socket_mode_enabled: false
        token_rotation_enabled: false

   9. "Next"를 클릭.
   10. "Create"를 클릭.
   11. "Install App to Workspace"를 클릭.
   12. "Allow"를 클릭.
   13. 사이드바에서 "OAuth & Permissions"를 클릭.
   14. "Bot User OAuth Access Token"을 복사
       
   15. Jenkins에서: "Manage Jenkins → System"에서 Slack 설정으로 이동.
   16. Jenkins에서: "Add"를 클릭하여 새 "Secret text" 자격 증명을 생성하고 봇 사용자 토큰을 입력.
   17. Jenkins에서: 드롭다운에서 새 "Secret text"를 선택.
       
   18. Jenkins에서: 기본 채널을 추가
   19. Jenkins에서: "Custom slack app bot user" 옵션을 선택.
       
   20. 알림을 받으려는 Slack 채널에 Jenkins 봇 사용자를 초대.
   21. Jenkins에서: "test connection"을 클릭. 기본 채널 / 기본 멤버에게 메시지가 전송되는지 확인.
       
3. pipeline 코드
4. slackSend color: "good", message: "Message from Jenkins Pipeline"
5. 사용 예제

   1. pipeline {
          agent any
          stages {
              stage('Test') {
                  steps {
                      timestamps {
                          echo "hello world"
                      }
                  }
              }
          }
          post {
              success {
                  timestamps {
                      echo "Sending Slack notification"
                      slackSend(color: 'good', message: "Message from Jenkins Pipeline - ${currentBuild.fullDisplayName}")
                  }
              }
          }
      }

   2. 빌드 로그
      
   3. slack 메세지
      1. 

자료출처 : Gartner: The Top 10 Strategic Technology Trends For 2025 (Techrepublic.com) -  by  Ben Abbott

번역: COPILOT

1. AI를 의사결정 에이전트로 전환
2. AI 거버넌스를 위한 기술 플랫폼
3. 허위 정보 방어 도구
4. 포스트 양자 암호화로의 전환 
5. 주변 무선 태그 및 센서
6. 에너지 효율적인 컴퓨팅
7. 미래 컴퓨팅의 하이브리드화
8. 공간 컴퓨팅으로 현실 강화
9. 다기능 로봇
10. 신경학적 향상 기술

에이전틱 AI, AI 거버넌스 플랫폼 및 포스트 양자 암호화는 IT 리더들이 직면한 가장 파괴적인 미래 기술 트렌드 중 하나입니다

AI, 컴퓨팅 및 인간-기계 상호작용의 급속한 발전은 가트너가 2025년에 IT 리더들이 주의 깊게 모니터링해야 한다고 믿는 10가지 기술 목록의 주요 동인 (key drivers) 입니다.

가트너의 수석 부사장 애널리스트인 진 알바레즈는 9월 10일 호주에서 열린 IT 심포지엄/Xpo에서 향후 2년에서 10년 동안 혼란을 일으킬 가능성이 있는 기술 트렌드 목록을 공개했습니다. 연구와 분석에 따르면, 이 목록에는 'C-레벨 임원들 (CEO, CFO, COO, CTO, etc) 이 이에 대해 무언가를 해야 한다고 말할 정도로 중요한' 기술과 트렌드만 포함되어 있다고 합니다.

1. AI를 의사결정 에이전트로 전환

가트너는 에이전틱 AI가 향후 2~3년 내에 등장할 것으로 예상하며, 정보 요약과 같은 작업을 넘어 개인을 대신해 실제로 행동을 취하는 능력을 갖출 것으로 보고 있습니다. 사용자에게 옵션을 제시하는 대신, 허가를 받으면 사용자에게 최적의 옵션을 선택할 수 있게 될 것입니다.

2. AI 거버넌스를 위한 기술 플랫폼

모델 편향과 같은 우려로 인해 투명성과 윤리를 통해 신뢰를 구축하기 위한 AI 거버넌스 플랫폼과 도구가 개발되고 있습니다. 알바레즈는 이것이 AI가 생성한 답변의 설명 가능성과 유해한 정보 제공 방지를 가능하게 할 것이라고 설명했습니다."

SEE: Australia proposes mandatory guardrails for AI

3. 허위 정보 방어 도구

생성형 AI는 악의적인 행위자가 사람이나 조직을 사칭하는 가짜 비디오, 음성 및 이미지를 포함한 합성 미디어를 만들 수 있게 할 수 있습니다. 허위 정보 보안 도구는 조직이 진실을 평가하고 허위 정보의 확산을 추적하여 딥페이크( identify deepfakes)를 식별하거나 합성 미디어를 감지하는 데 도움을 줄 것입니다.

4. 포스트 양자 암호화로의 전환 

최근에 포스트 양자 암호화 표준이 발표되었습니다. 가트너에 따르면, 포스트 양자 암호화는 단 2~3년 내에 중요한 문제가 될 것입니다. IT 리더들은 곧 모든 암호화를 고전 컴퓨팅이나 양자 컴퓨팅으로 깨지지 않는 포스트 양자 알고리즘으로 교체해야 할 필요가 있을 것입니다.

- Post-quantum cryptography standards

5. 주변 무선 태그 및 센서

재고, 공급망 상태 또는 물리적 자산을 추적하고 모니터링할 수 있는 무선 태그 및 센서의 비용이 하락함에 따라, 조직은 이전에 '그림자 속에' 있던 운영 부분의 데이터에 접근하고 대응할 수 있게 될 것입니다."

6. 에너지 효율적인 컴퓨팅

탐색 조직은 곧 에너지 집약적인 알고리즘을 친환경 클라우드 제공업체로 이전하거나, 에너지를 덜 소비하도록 알고리즘을 다시 작성하거나, 생성형 AI의 에너지 사용을 더 면밀히 모니터링하기 시작할 수 있습니다. 광학, 뉴로모픽 및 DNA 저장과 같은 추가 기술은 엄청난 효율성 향상을 가져올 수 있습니다.

- How Australia is striving to lead in both AI and sustainability

7. 미래 컴퓨팅의 하이브리드화

조직은 미래에 하이브리드 컴퓨팅 접근 방식을 취할 것으로 예상됩니다. 알바레즈는 CPU, GPU, 엣지 컴퓨팅, 양자 컴퓨팅, 광학 컴퓨팅 및 DNA에 정보를 저장하는 것을 포함하여 여러 다른 컴퓨팅 패러다임과 기술을 통합하고 조정할 가능성이 있다고 말했습니다.

8. 공간 컴퓨팅으로 현실 강화

공간 컴퓨팅은 증강 현실 헤드셋과 같은 장치를 통해 물리적 및 디지털 영역을 단일 통합 3D 공간으로 결합합니다. 알바레즈는 제조 현장과 같은 장소에서 의사 결정을 위한 적시 상황 설명을 지원할 수 있는 장치와 애플리케이션이 개발되고 있다고 말했습니다.

9. 다기능 로봇

3년에서 10년 사이에 여러 기능을 수행할 수 있는 다기능 로봇이 일상 생활의 일부가 될 것으로 예상됩니다. 알바레즈는 2030년까지 80%의 사람들이 일상적으로 스마트 다기능 로봇과 상호 작용할 수 있을 것이라고 말했습니다.

10. 신경학적 향상 기술

뇌 기능을 읽고 향상시킬 수 있는 기술 개발은 시각이나 청각과 같은 감각을 회복하기 위해 의료 시설을 포함한 환경에서 사용될 수 있습니다. 그러나 가트너는 이것이 최소 10년 동안은 일어나지 않을 것이라고 말합니다. 장치는 이어버드나 헤드밴드와 같은 간단한 웨어러블 장치부터 복잡한 통합 뇌-컴퓨터 인터페이스에 이르기까지 다양할 것입니다.

기술 트렌드를 무시하는 것은 위험하다고 가트너는 경고합니다

알바레즈는 IT 리더들이 지금 행동할 기술, 모니터링할 기술, 무시할 기술을 스스로 결정해야 한다고 말했습니다. 그러나 그는 가트너의 전략적 기술 트렌드를 무시하기로 선택한 사람들에게 주의를 촉구하며, '파도를 등지면 넘어질 수 있다'고 말했습니다."

자료출처: Gartner's Top 10 Strategic Technology Trends for 2024 (techrepublic.com) Written ByEsther Shein

번역: COPILOT

가트너(Gartner)의 최신 기술 트렌드 보고서에서 인공지능이 주목을 받고 있으며 상위 세 가지 위치를 차지하고 있습니다. 가트너는 조직이 2024년에 탐구해야 할 10가지 주요 전략기술 트렌드를 발표했습니다. 상위 세 가지 트렌드가 모두 다양한 유형의 인공지능과 관련되어 있어서 놀라운 일은 아닙니다.

가트너 부사장 분석가인 **바트 윌렘센(Bart Willemsen)**은 "지난 몇 년 동안 그리고 2023년까지 AI와 함께 작업을 시작한 조직 수가 급증했습니다. 이러한 추세는 더욱 더 빨라질 것으로 예상됩니다"라고 TechRepublic과의 이메일 인터뷰에서 말씀하셨습니다 .

2024년을 위한 **가트너(Gartner)**의 상위 10가지 전략 기술 트렌드는 다음과 같습니다. 순위별로 나열해 보겠습니다:

1. 보편화된 생성 AI (Democratized Generative AI).
2. AI 신뢰, 위험 및 보안 관리 (AI Trust, Risk, and Security Management).
3. AI-증강 개발 (AI-Augmented Development).
4. 지능형 응용 프로그램 (Intelligent Applications).
5. 증강-연결 된 노동력 (Augmented-Connected Workforce).
6. 기계 고객 (Machine Customers).
7. 지속적인 위협 노출 관리 (Continuous Threat Exposure Management).
8. 지속 가능한 기술 (Sustainable Technology).
9. 플랫폼 엔지니어링 (Platform Engineering).
10. 산업 클라우드 플랫폼 (Industry Cloud Platforms).

이러한 트렌드들은 기업과 기술 리더들이 내년에도 주목해야 할 분야로, 전략적 기술 투자 로드맵을 수립하는 데 도움이 될 것입니다.

1. **보편화된 생성 AI(Democratized Generative AI)**는 현재 조직들이 우선적으로 고려하고 있는 트렌드입니다. 가트너(Gartner)에 따르면, 이는 대규모 사전 훈련된 모델, 클라우드 컴퓨팅, 오픈 소스의 융합으로, 이러한 모델을 전 세계 노동자들이 접근할 수 있도록 하는 것을 의미합니다. 가트너는 2026년까지 80% 이상의 기업이 GenAI API와 모델을 사용하거나 GenAI 활성화된 애플리케이션을 프로덕션 환경에서 배포할 것으로 예측하고 있습니다. 이는 2023년 초보다 적은 5%에서 상승한 수치입니다.

많은 조직이 이미 AI와 작업하고 있지만, ChatGPT와 기타 GenAI 플랫폼에 의한 관심이 조사 결과로 나타나며, 이로 인해 응답자의 45%가 AI 예산을 늘리고 있다고 설명했습니다 .

2. **AI 신뢰, 위험 및 보안 관리 (AI Trust, Risk, and Security Management)**은 이러한 노력의 강도를 보장하기 위해 조직은 실제로 프로덕션에 도달하는 AI 프로젝트의 가능성을 높일 수 있는 예방적인 조치에 집중해야 합니다. 가트너(Gartner)는 이를 "AI TRiSM"이라고 부르며, 이는 전반적으로 AI 신뢰, 위험 및 보안 관리 프로그램으로, 미리 통합된 거버넌스를 지원하고 AI 시스템이 준수되고 공정하며 신뢰성 있으며 데이터 프라이버시를 보호하도록 사전에 적극적으로 보장합니다.

이는 "과거 실패의 끔찍한 숫자를 피하고 AI 기술을 사용할 때 처음부터 고려해야 할 트렌드 중 하나로, 설명 가능성, 신뢰성, 프라이버시 및 보안을 높이는 데 도움이 됩니다"라고 그는 말했습니다.

3. **AI-증강 개발 (AI-Augmented Development)**은 인공지능 기술을 활용하여 소프트웨어 엔지니어가 애플리케이션을 설계, 코딩 및 테스트하는 데 도움을 주는 방법입니다. 이는 GenAI와 머신러닝과 같은 인공지능 기술을 사용하여 소프트웨어 엔지니어가 코드 작성에 덜 시간을 할애할 수 있도록 합니다.

이러한 AI-포함 개발 도구를 사용하면 소프트웨어 엔지니어가 더 전략적인 활동에 시간을 투자할 수 있게 됩니다. 예를 들어 흥미로운 비즈니스 애플리케이션을 설계하고 구성하는 데 더 많은 시간을 할애할 수 있습니다. 이는 개발자의 생산성을 향상시키고 비즈니스 운영에 필요한 소프트웨어 수요를 충족시킬 수 있도록 합니다.

AI-증강 개발을 준비하는 것은 "개발 주기에서 주요 병목 현상이 어디에 있는지 명확하게 파악하는 것"이라고 Willemsen은 지적했습니다. 이는 애플리케이션 코드 생성, 레거시 코드를 현대 언어로 변환, 디자인에서 코드로의 변환 및 애플리케이션 테스트 기능 강화 등을 포함할 수 있습니다.

“소프트웨어 엔지니어 팀이 평가, 테스트 및 설정을 주로 수행하도록 하세요. 결국 그들이 이 작업을 수행해야 하기 때문입니다,” 그는 조언했습니다.

4. **지속적인 위협 노출 관리(CTEM)**은 조직이 사이버 보안 검증 접근 방식을 자동화할 수 있도록 하는 체계적인 변화입니다.

이러한 접근 방식을 시작하려면 침해 및 공격 시뮬레이션 또는 자동화된 침투 테스트 도구를 구현하고, 점진적으로 공격자의 시각을 체계적으로 적용하여 공격이 성공할 수 있는지 여부를 확인해야 합니다.

가트너는 2026년까지 CTEM 프로그램을 기반으로 보안 투자를 우선순위로 정하는 조직은 침해 사고를 3분의 2 이상 줄일 수 있다고 예측하고 있습니다

5. **기계 고객(Machine Customers)**는 때로는 "custobots"라고도 불리며, 지불을 위해 자율적으로 협상하고 상품 및 서비스를 구매할 수 있는 비인간적인 경제 주체입니다. 가트너(Gartner)에 따르면, 2028년까지 150억 개의 연결된 제품이 고객으로서 행동할 수 있는 잠재력을 갖추게 될 것으로 예측되며, 이후 몇 년 동안 더 많은 수의 제품이 이어질 것입니다.

“기계 고객 기회를 활용하는 것은 기술이나 마케팅과 관련이 없습니다,” Willemsen은 지적했습니다. “이것은 모든 경영진이 참여해야 할 비즈니스 기회입니다. 모든 C-레벨 임원은 자신이 어디에 속하는지 결정해야 합니다. 팀 전체의 협력 없이는 진전이 부분적이고 효과가 없으며 결정적이지 않을 것입니다.”

6. **지능형 응용 프로그램(Intelligent Applications)**은 학습된 적응력을 갖추어 적절하고 자율적으로 응답하여 작업을 더 효과적으로 보완하거나 자동화하는 애플리케이션을 의미합니다. 이러한 응용 프로그램의 지능은 머신러닝, 벡터 저장소 및 연결된 데이터와 같은 다양한 AI 기반 서비스로 구성됩니다.

가트너(Gartner)는 "지능형 응용 프로그램에 대한 명확한 필요성과 수요가 존재한다"고 언급했습니다. 가트너의 2023년 CEO 및 고위 경영진 조사에서 26%의 CEO가 지속적인 인재 부족을 조직에 가장 큰 위험 요소로 지적했습니다. CEO 응답자들은 인재 유치와 유지를 최우선 인력 우선 사항으로 지목했으며, 다음 세 해 동안 가장 큰 영향을 미칠 기술로 AI를 지목했습니다

7. **증강-연결 된 노동력(Augmented-Connected Workforce)**는 인간 근로자의 가치를 최적화하기 위한 전략으로, 인공지능 애플리케이션과 노동력 분석을 활용하여 노동자의 경험, 웰빙 및 기술 개발 능력을 지원합니다. 동시에 비즈니스 결과를 도출합니다.

가트너(Gartner)에 따르면, 2027년까지 CIO의 25%가 핵심 역할의 역량 향상 시간을 50% 줄이기 위해 증강-연결 된 노동력 이니셔티브를 활용할 것으로 예측되고 있습니다

8. **지속 가능한 기술(Sustainable Technology)**은 환경, 사회 및 거버넌스 결과를 가능하게 하는 디지털 제공 프레임워크입니다. 이는 인공지능, 암호화폐, 사물 인터넷 및 클라우드 컴퓨팅과 같은 기술의 에너지 소비에 대한 우려가 커지면서 주목받고 있습니다.

IT 관점에서 이 문제를 해결하는 것에는 좋은 동기가 있습니다. 가트너(Gartner)는 2027년까지 CIO의 25%가 지속 가능한 기술의 영향과 개인 보상을 연결할 것으로 예측하고 있습니다

9. **플랫폼 엔지니어링(Platform engineering)**은 여러 애플리케이션과 서비스를 지원할 수 있는 소프트웨어 플랫폼의 설계, 개발, 운영을 다루는 분야입니다. 이러한 플랫폼은 전용 제품 팀에 의해 생성 및 유지되는 레이어를 가지며 사용자의 요구를 지원하기 위해 도구 및 프로세스와 상호 작용합니다. 플랫폼 엔지니어링의 목표는 생산성과 사용자 경험을 최적화하고 비즈니스 가치의 전달을 가속화하는 것입니다.

참고 자료: TechRepublic의 플랫폼 엔지니어 채용 키트

10. **산업 클라우드 플랫폼(Industry Cloud Platforms)**은 기업의 산업별 비즈니스 결과를 지원하기 위해 기본 SaaS, PaaS 및 IaaS 서비스를 조합하여 구성 가능한 기능을 갖춘 제품으로 제공합니다. 일반적인 요소에는 산업 데이터 패브릭, 패키지화된 비즈니스 기능 라이브러리 및 구성 도구가 포함됩니다.

https://hbr.org/2020/03/best-practices-for-instant-messaging-at-work  (2020 년 03월 by Dustin York)

이 포스트는 위의 Dustin York 의 Best Practices for Instant Messaging at Work 내용을 ChatGPT 를 통해 요약하였습니다.

- 직장내 인스턴트 메신저 사용에 대한 모범 사례는 다음과 같습니다.

1. 목적과 용도를 명확히 이해하세요: 인스턴트 메시징은 실시간 소통과 빠른 결정에 유용하지만, 전화나 이메일 등 다른 커뮤니케이션 도구와는 목적과 용도가 다릅니다. 간단한 질문, 업무 업데이트, 미팅 일정 확인 등의 일상적인 대화에 사용하되, 복잡한 주제나 중요한 결정에는 더 적합한 도구를 사용하는 것이 좋습니다.

2. 적절한 메시지 전달 시기: 인스턴트 메시징은 실시간으로 이루어지지만, 상대방이 바쁠 수도 있으므로 메시지를 전달할 때 적절한 시간을 선택해야 합니다. 업무 시간에 다른 사람을 방해하지 않도록 주의하고, 긴급한 문제가 아니라면 비즈니스 시간 외에는 보내지 않는 것이 좋습니다.

3. 명확하고 간결한 메시지 작성: 인스턴트 메시징은 일반적으로 짧은 메시지를 주고받기 때문에 명확하고 간결하게 작성하는 것이 중요합니다. 불필요한 세부사항을 제거하고, 필요한 정보를 명확하게 전달하세요. 길고 복잡한 메시지는 효율성과 이해도를 저해할 수 있습니다.

4. 존중과 전문성 유지: 인스턴트 메시징은 빠르고 비공식적인 소통 방법이지만, 직장에서도 존중과 전문성을 유지해야 합니다. 다른 사람의 시간과 일정을 고려하고, 적절한 인사말과 단정한 언어를 사용하세요. 또한, 감정적인 반응이나 논쟁을 피하고, 긍정적이고 협력적인 태도를 유지해야 합니다.

5. 개인정보와 보안 유의: 인스턴트 메시징은 정보를 빠르게 공유하는 도구이므로 개인정보나 기밀 정보를 신중하게 다루어야 합니다. 개인정보를 포함한 민감한 정보는 보안을 강화한 다른 도구를 사용하는 것이 좋습니다. 또한, 악의적인 링크나 파일에 대한 조심도 필요합니다.

6. 적절한 그룹 채팅과 채널 사용: 인스턴트 메시징 플랫폼은 그룹 채팅이나 채널 기능을 제공합니다. 이를 통해 특정 프로젝트나 팀에 대한 대화를 진행할 수 있습니다. 필요한 경우 적절한 그룹 채팅을 만들고 관련 인원들을 초대하여 커뮤니케이션의 효율성을 높일 수 있습니다.

7. 기록과 검색 가능성: 인스턴트 메시징은 대화의 기록을 남기기 때문에 필요한 정보를 나중에 찾을 수 있습니다. 필요한 정보를 빠르게 검색하고 참조할 수 있는 방법을 익히고, 중요한 결정이나 약속은 다른 도구에도 기록하는 것이 좋습니다.

8. 효과적인 알림 관리: 인스턴트 메시징은 즉각적인 알림을 제공하기 때문에 알림 관리가 중요합니다. 중요한 메시지에 대해서만 알림을 받도록 설정하고, 직장 외의 시간에는 알림을 꺼두는 등 개인의 작업 흐름에 맞춰 알림을 관리하세요.

9. 비상 상황에서의 사용: 인스턴트 메시징은 긴급한 상황에서 유용할 수 있습니다. 하지만 심각한 긴급 사태에 대해서는 더욱 빠른 응답이 필요하므로, 전화나 대면 소통을 우선으로 고려하는 것이 좋습니다. 비상 시나리오에 대비하여 대체 커뮤니케이션 방법을 항상 알아두는 것이 좋습니다.

이러한 모범 사례를 따르면 인스턴트 메시징을 효과적으로 활용하여 직장에서의 효율성과 협업을 향상시킬 수 있습니다.

이번 포스팅에서는 Services 내 jenkins 서비스를 찾아 Status 를 Stop 으로 하고 나서,  특정 폴더 내 폴더들 및 파일들을 찾아 삭제를 하는 FolderControlCore 코드를 확인 해 본다.

1. Service (0) 을 던져, 서비스를 멈추고 나서 foreach 를 실행한다. 이때 deleteFolderName 은 스트링 배열로, Main code 에 다음과 같이 선언되어 있다. 

2. 배열 갯수만큼 foreach 가 돌면서 folderName 이 하나씩하나씩 클래스 멤버로 설정이 되며, SearchAndDeleteFolders() 메소드를 실행 시킨다. - 예) lastStable

3. SearchAndDeleteFolders() 메소드 는 설정된 directoryName 으로 폴더를 우선 찾아본다. SearchDirectories() 의 결과를  folderFound 변수에 담아 Count 확인 후, DeleteDirectories() 를 호출한다.

4. SearchDirectories() 메소드는 .Net 에서 지원하는 Directory 클래스 내 GetDirectoreis 메소드를 사용하여 검색한다. 이때 특정 폴더 (upperDirectoryName = %Jenkins HOME% ) 와 지울 폴더 (예) lastStable) 가 있는지 검색 하여 검색 결과를 IEnumerable<string> folderFound 로 전달한다.

5. DeleteDirectories() 메소드에서는 전달받은 폴더 경로들(list) 을 다시 한번 CheckPath() 메소드로 string 이 파일경로 형태의 string 포멧인지를 확인한다. CheckPath() 는 True/False 값을 넘기며, 경로확인이 되었을 때 .net framework 에서 지원하는 Directory 클래스의 Delete() 메소드를 이용하여 경로(path)를 삭제한다.

6. CheckPath() 는 정규 표현식으로 path 문자열을 확인 한다. .net framework 내 Regex 클래스의 IsMatch 메서드는 지정된 패턴과 경로 문자열이 일치하는지 확인하며, 일치하는 경우 메서드는 true를 반환하고, 그렇지 않은 경우 false를 반환한다.

• ^는 문자열의 시작을 나타냄
• (([a-zA-Z]:)|(\))는 드라이브 문자와 : 또는 단일 백슬래시()와 일치하는지 확인
• (\{1}|((\{1})^\)+)는 나머지 경로를 일치시키며, 백슬래시() 다음에는 , :, *, ?, <, >, ", |가 아닌 문자열의 시퀀스가 와야 하며, 이 패턴은 여러 번 반복 가능하다.

7. 각 폴더별 (예: lastStable ) 로 찾은 폴더 갯수 및 삭제한 폴더 갯수, 그리고 지워지지 않은 폴더 갯수를 로그파일에 남긴다. 갯수 위에는 폴더 경로들이 찍히며, 총 4번이 찍히게 된다.

이렇게 foreach() loop 이 완료되면 ServiceControlCore 의 메소드인 ControlService(1) 을 호출하여 Jenkins 서비스를 재시작한다.

사실 현재 사용하는 프로그램에 대한 설명은 완료 되었지만, Jenkins 서비스를 강제 shutdown 시키는 방법보다는 safe-shutdown 시키는 방법을 권장 된다. 이 방법은 Jenkins 내 shutdown 명령어가 적용 될 때, 실행 시작이 된 프로세스가 있는지 확인 하며, 완료 후 shutdown 실행이 되는데, 이 방법을 사용하려면 프로그램 안에서 cmd 명령어를 실행 시켜 진행한다. 다음 포스팅에서 이부분에 대해 알아보려고 한다.

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)

젠킨스 (Zenkins) 구성 중에 3분마다 서비스가 살아있는지 확인하는 구성이 하나 있었는데, 처음에 크론탭 (Chrontab) 설정 할때는 다음과 같이 설정하여 3분마다 지속적으로 확인 할 수 있도록 했습니다.

H/3 * * * *

이후에, 서비스 사용하는 시간 동안에만 확인 하도록 설정을 다음과 같이 바꾸게 되었습니다. 사실 크론탭 설정 관련하여 지식이 없어, chatGPT 의 도움을 받았습니다. Schedule 은 월-금, 오전 8시부터 오후 19시 이전까지 걸어놨습니다. 

*/3 8-18 * * 1-5

• */3 in the first field means "every third minute"
• 8-18 in the second field means "between 8:00 AM and 6:59 PM"
• * * in the third and fourth fields means "every day of the month" and "every month of the year" respectively
• 1-5 in the fifth field means "Monday to Friday"
• -- from ( openai.com )

이틀간의 빌드 히스토리를 열어서 UTC 를 한국 시간으로 수정한 결과 입니다.

src/main/webapp directory will be ignored if packaged as a Jar

it works only with War packaging

Tool 개발 로그 - 1-1 #Jenkins #서비스 #재시작 + @작업하는 #Tool 만들기 c# -배경 #시나리오

* 2020년 9월에 작성 된 Tool의 개발 로그, 2번째 프로그램 작성 ServiceControlCore 설명이다. 

- Windows OS 내 Services (서비스) 툴에 등록 된 서비스 를 멈추고 시작하고, 상태를 확인할 때, 유용하게 사용할 수 있도록 제공 된 닷넷 클래스가 있다. 이름은 ServiceController 이며 이에 대한 상세 설명은 다음 링크에 기록되어 있다. -  https://learn.microsoft.com/ko-kr/dotnet/api/system.serviceprocess.servicecontroller?view=dotnet-plat-ext-7.0

이 클래스를 사용하여 서비스 상태를 가지고 오고, 멈춘 뒤, 필요한 작업을 진행 하고, 마지막에 서비스를 다시 시작한다. 해당 프로그램의 배경 시나리오 포스트( https://yobine.tistory.com/582 ) 에서 작성 된 프로그램의 전체 플로우와 동일하다. 

이번 포스팅에서는 ServiceControlCore 클래스 내 있는 Method 들을 살펴 본다. 상단에 언급했듯 이 ServiceControlCore 클래스 에서는 닷넷에서 제공하는 ServiceController 클래스를 사용하여 Jenkins 서비스의 상태를 확인하고 변경한다.

프로그램에서 제일 처음에 호출 하는 작업이 GetServices() 메소드 이다. 

이 메소드는 Jenkins 서비스 상태를 확인하는 부분인데, 리턴 값은 bool 이며. 선언된 serviceName (Jenkins) 과 Services[] 로 받아온 리스트를 비교 하여, ServiceName 이 리스트에 있는지 우선 확인 하며, 서비스 이름이 Services 에 등록되어 있다면 현재 상태를 확인 하고, running 인 경우 true 를 반환한다. 

- 서비스가 언제나 running 인 상태여야 프로그램이 돌기 때문에, 이부분에 대해 수정이 필요할 것 같다. 

다음은 ControlService() 메소드 다. 이 메소드에서 서비스를 실질적으로 멈추고, 시작한다. 우선 int flag 를 인자로 , 0은 서비스 멈춤 (Stop), 1은 서비스 시작 (Start) 으로 약속된 값을 전달 받는다. 실행 중인 Jenkins 서비스(serviceName )를 멈추고(Stop)  20초 timeout 시간을 걸어주는데, 서비스가 멈추는데 걸리는 시간이 대략 최대 20초 정도여서, 멈출 때까지 대기를 하지만, 대부분 20초 전에 멈추기 때문에 대기 시간으로써는 충분한 시간이다.

ControlService() 메소드 에서 flag 값에 따라 분기가 일어나는데, if/else 가 아닌 switch 문을 사용했다. 1과 0 만이 아닌 그외의 명령어 까지 전달을 생각으로 메소드를 작성했다. 내부적으로 시작 혹은 멈추는 명령어를 전달 후, 서비스 상태를 2초마다 확인하는데, 이 메소드 이름은 CheckServiceStatus(int flag) 이다. 이 메소드 는 ControlService(int flag) 메소드에서 전달 받은 동일한 인자 flag 를 받아 GetService() 메소드를 호출하여 상태를 확인 한다. 

서비스를 Stop (0) 을 시켜야 하는데, GetService 의 리턴 값이 true 면, 다시 동일한 flag 값 (0) 을 가지고 재귀호출을 한다. 만약 GetSerivce 의 리턴값이 false 라면, break 가 걸리고, 서비스가 멈추었다는 로그를 남긴다. 

서비스를 Start(1) 하는 내용도 동일하다. 리턴값들이 반대이지만, 동일하게 작동한다. 

해당 프로그램을 실행하면 위의 CMD 화면과 같이 화면에 로그들이 찍힌다. 처음에 Jenkins 서비스를 찾았고, 실행 중인 것이 확인 되어 재시작 프로세스가 시작되었다고 나오며, 서비스를 멈추게 한다. 서비스가 멈춘 후 삭제해야 할 폴더들을 각각 찾아서 삭제를 진행 하게 되며, 작업이 끝난 후에 다시 Jenkins 서비스를 실행 한다. 

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)

 * 2020년 9월에 작성 된 Tool의 개발 로그입니다.

회사에서 사용하고 있는 Jenkins 가 간혹 이상 증상을 일으키는데, 그 중 하나는 Windows OS 를 사용하는 Slave-node 들이 모두 off-line 으로 변경 된다.

- 참고로 Jenkins 를 Master-Slave node 로 구성하는 내용은 다른 블로그에 많이 적혀 있으므로 여기서는 생략하며 아래 링크에 간략한 구성도 포함되어 공유한다. 

- https://velog.io/@doontagi/Jenkins-Master-Slave-%EA%B5%AC%EC%84%B1 

다시 본론으로 돌아오면,

사용 중 인 Jenkins 버전 (2.13) 버그여서, Jenkins 를 상위 버전으로 업그레이드를 하게 되면 없어지는 현상이지만, 해당 Jenkins 에 등록되어 배포 중 인 프로젝트들도 많고 (20+), 설치 된 플러그인들 중, 해당 버전의 Jenkins 에서는 잘 사용 중이지만, 상위 버전에서는 지원이 끊겨, 업데이트를 시도 했다가, 여러 문제가 발생하여 다시 현재 버전의 Jenkins 로 롤백하게 되었고, 버그 발생도 감안하며 사용 중 이다.

이 후 2.13 버전의 Jenkins 서비스엔 새로운 개발 프로젝트 등록은 하지 않기로 결정이 났고, 사용 중인 프로젝트들만 요청 시 따로 분리하는 작업을 진행 했지만 원치 않는 부서들이 더 많아서, 오류 발생 연락이 왔을 때, 바로 조치를 취해 줘야 한다.

Windows OS 를 사용하는 Slave-Node 들이 모두 off-line 으로 변경되는 오류 발생 시 취해야 하는 방법은, 인터넷 검색을 통해 다음과 같이 정리 되었다. 

1. safeRestart : https://jenkins.url.com/safeRestart 를 실행 해 준다. CentOS 등을 사용하는 Slave-agent 들이 돌고 있을 수도 있어서 해당 agent 들의 job 이 완료되면 Jenkins 서비스 재실행이 될 수 있도록 한다. (Windows OS 의 Slave-node 로 배포 하는 프로젝트 들은 강제로 끊어줘야 한다. - 배포 job 실행 후 slave node 가 off-line 이여서 slave node 가 on-line 이 되기 를 기다리며서 job 진행 중이 되므로, safeRestart가 불가능하다. 
2. Jenkins 서비스가 멈춘 뒤, 재시작이 진행 되었을 때, 거의 100 이면 100, 모두 오류가 나면서 서비스 재시작 실패를 하는데, 주로 다음과 같은 오류가 난다. 빨간색으로 표기한 lastStable 이라는 폴더 외에도 lastStable 이라를 폴더들 관련 ioException 오류들이 표시됩니다.

3. 이 상태에서는 Jenkins 서비스가 재시작을 계속 실패한다. 이때, %Jenkins HOME%/jobs 폴더 내 프로젝트 구성 폴더들 안에 있는 lastStable, lastSuccessful 폴더들을 모두 검색하여 삭제해야 한다. 이후 Jenkins 서비스를 재시작을 하면 성공적으로 서비스가 재시작 및 실행 중인 걸 확인 할 수 있다.

한동안은 위의 1,2,3 번 스텝을 slave-node 가 off-line 되는 현상이 있을 때마다 수작업으로 진행 하였는데, 서버 접속 해서 cmd 열고, 서비스 stop 명령어 전달 하고 서비스가 멈추고 나면, 3번 스텝에 언급된 폴더들을 검색하여 삭제 하고, jenkins 서비스의 재시작 누른 후.. 실행을 확인 하게 되는데, 걸리는 시간이 서버 및 네트워크 상태에 따라 족히 15분-30분까지도 걸리는 작업이다. 

정규 배포 날에 해당 문제가 발생하면 이전 버전을 그냥 사용하면서 배포 가능한 시간을 기다릴 수 있지만, 오류패치 배포 등 긴급한 상황인 경우엔 15분도 너무 긴 시간이다. 그래서 클릭 한번으로 서비스 내리고, 폴더들 삭제 하고, 다시 서비스를 올리는 프로그램이 필요했고, 그래서 다음과 같이 만들게 되었다.

결론적으로는 프로그램 실행 후 모든 작업이 완료되기까지 소요되는 시간은 평균적으로 2분에서 3분정도 이며 (대부분 미만의 시간이 걸림), 이후 서비스 재시작하기까지 2-3분정도 걸린다. 빠르게 오류 발생 시 대처할 수 있게 되었다.

자 이제부터는 프로그램 코드를 공유 한다. 프로그램 언어는 c# 이며, 사용된 닷넷 버전은 4.0 이다.

서버에서 정기적으로 해당 어플리케이션(.exe) 을 실행 하여 젠킨스 서비스를 재시작하여 불시의 오류를 대비하기 위해 만드는 프로그램이여서, 콘솔앱이며 진행사항을 콘솔 및 로그 파일에 기록한다. - 하지만 불필요하게 서비스를 재시작하기 때문에, 오류 발생 시에만 사용하기로 정하였음.

이제 만들 프로그램은, 기본적으로 app.config 에 들어 있는 위의 정보들을 사용하여, 순차적으로 실행된다. Class 가 2개가 있는데 하나는 ServiceControlCore 라고 이름은 거창하지만, Jenkins 라는 서비스이름 과 타임아웃 시간을 받아 생성되는 객체다. FolderControlCore 역시 이름만 거창할 뿐, 상위 폴더 이름과 삭제할 타겟 폴더 이름을 받아, 폴더 검색, 폴더 확인 및 폴더 삭제를 진행 한다. 

A.     설치된 서버 에서 Windows Services 에 등록되어 있는 특정 서비스 검색 (serviceName = Jenkins ) 후 서비스가 실행 중인지 확인한다. bool 값을 리턴받아 다음 단계를 진행한다. 

B.     실행 중인 Jenkins 서비스(serviceName )를 멈춘다. 멈추고(Stop)  20초 timeout 시간을 걸어주는데, 서비스가 멈추는데 걸리는 시간이 대략 최대 20초 정도이다.

C. 프로그램 상단에 생성 시 객체에 지정 해 준 상위 폴더 (upperDirectoryName = %Jenkins HOME% ) 이름 아래에 있는 삭제할 타겟 폴더 (deleteFolderNameList ) 들을 하나 씩 전달하여 타겟 폴더 갯수 만큼 순차적으로 검색 후 삭제를 진행 한다. 

D. Jenkins 서비스 (serviceName=Jenkins)  를 시작한다.( 시작 후 최대 대기 시간 20초)

E.     Log 추가 (NLog 패키지 활용)

NLog 패키지 설정 및 활용에 대해서는 따로 설명은 생략 하므로 잘 작성 된 블로그를 공유한다.

- 참조: https://icodebroker.tistory.com/9402

이로써 프로그램은 잘 만들어졌고, 이번 프로그램에서 작성 한 FolderControlCore 와 ServiceControlCore 에 대해서 다음에 좀더 자세히 살펴 보기로 한다.

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)