반응형
반응형
폐쇄망 파일전송 망연계 환경에서 A 서버에서 C 서버로 nc 테스트가 실패하는 이유와 점검 방법``` 폐쇄망에 있는 A 서버에서 외부망의 C 서버로 파일을 전송하기 위해 망연계 B 서버를 경유하는 환경에서는 nc -zv C_IP PORT 명령이 실패할 수 있습니다. 특히 망연계 방식이 파일전송 전용 망연계라면 A 서버와 C 서버 사이에 직접 TCP 세션이 생성되지 않기 때문에, 이 결과만으로 방화벽 정책이나 망연계 장애를 판단하면 안 됩니다. 핵심 결론: 파일전송 망연계 환경에서는 A 서버가 C 서버의 업무 포트로 직접 접속하지 않습니다. 따라서 A 서버에서 C 서버를 대상으로 실행한 nc 테스트가 실패하는 것은 정상일 수 있습니다. 정상 여부는 실제 망연계 통신 구간, ..
WildFly·JBoss WAR 배포 시 WFLYSRV0153 PARSE 오류 원인과 해결 방법WildFly 또는 JBoss EAP에 WAR 파일을 배포할 때 다음과 같은 오류가 발생할 수 있습니다.ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4)MSC000001: Failed to start servicejboss.deployment.unit."test.war".PARSE:org.jboss.msc.service.StartException:WFLYSRV0153: Failed to process phase PARSEof deployment "test.war"핵심 판단:배포 디렉터리에 WAR 파일이 2개 있었고, 하나를 삭제한 뒤 정상 배포되었다면 두..
WebtoB·JEUS 대신 WildFly를 선택하는 이유 국내 기업과 공공기관의 전통적인 Java 시스템에서는 WebtoB를 웹 서버로, JEUS를 웹 애플리케이션 서버로 사용하는 구성이 익숙하다. 그러나 신규 시스템이나 클라우드 전환 프로젝트에서는 WildFly 같은 오픈소스 애플리케이션 서버를 검토하는 사례도 늘고 있다. 단순히 라이선스 비용을 줄이기 위해서가 아니라 표준 기술 활용, 개발 환경 통합, 컨테이너 배포와 자동화 측면에서 선택지가 달라졌기 때문이다. 먼저 알아둘 핵심 WebtoB는 웹 서버이고 JEUS와 WildFly는 웹 애플리케이션 서버이므로 완전히 같은 제품을 일대일로 비교하는 것은 정확하지 않다. 실제 비교 대상은 Webto..
Ingress NGINX 대안으로 보는 NGINX Gateway Fabric과 Istio 비교 Kubernetes에서 Ingress NGINX을 대체하려고 하면 NGINX Gateway Fabric과 Istio가 자주 후보로 등장한다. 그러나 두 제품은 같은 범위의 도구가 아니다. NGINX Gateway Fabric은 외부에서 들어오는 트래픽을 처리하는 게이트웨이에 가깝고, Istio는 외부 트래픽과 서비스 간 통신까지 관리하는 서비스 메시다. 핵심 결론 외부 HTTP·HTTPS 라우팅과 Gateway API 전환이 목적이라면 NGINX Gateway Fabric이 더 직접적인 선택이다. 서비스 간 mTLS, 워크로드 기..
Tomcat 방식과 Pod 방식 차이, WAS 운영 구조 쉽게 이해하기 핵심 요약 Tomcat 방식은 서버나 VM 위에 Tomcat을 직접 설치해 WAR 파일을 배포하는 기존 WAS 운영 방식입니다. Pod 방식은 Tomcat을 컨테이너 이미지로 만들고 Kubernetes에서 Pod 단위로 실행하는 방식입니다. 쉽게 말하면 차이는 “Tomcat을 서버에 직접 설치하느냐, 컨테이너로 만들어 Kubernetes에서 운영하느냐”입니다. 요즘 인프라에서는 WAS 운영 방식을 설명할 때 Tomcat 방식과 Pod 방식을 구분해서 말하는 경우가 많습니다. 둘 다 애플..
Jakarta EE 10에서 11로 올릴 때 Spring 환경의 주요 리스크 Jakarta EE 10에서 Jakarta EE 11로 넘어가는 변화는 과거의 javax.*에서 jakarta.*로 바뀌던 수준의 대격변은 아닙니다. 하지만 기존 Spring 환경에서는 Java 버전, Spring Framework 세대, 내장 서버, JPA, Validation, XML/SOAP 연계 라이브러리에서 실제 장애가 발생할 수 있습니다. 핵심은 Jakarta EE 11 API만 올린다고 업그레이드가 끝나는 것이 아니라는 점입니다. 관리자 입장에서 보면 애플리케이션 코드보다 의존성 트리, 런타임 서버, 빌드 도구, 테스트 환경의 불일치가 먼저 문제를 일으키는 경..