open source magazine

Cloud Native 세미나

오픈소스 S/W ( U2L )워크샵

한국증권거래소, KT 차세대 ERP 그리고 국가정보자원관리원에서 매년 진행되는 수 백개의 프로젝트들의 공통점은 무엇일까요?바로 Unix에서 Linux 로 전환하는 U2L(Unix2Linux) 프로젝트들 입니다. 원하는 시간과 장소를 알려주시면 맞춤형 세미나를 진행합니다.

Outposts, Arc , Anthos with Kubernetes

Azure Arc vs. Google Anthos vs. AWS Outposts

대표적인 클라우드 서비스 업체인 Amzon AWS, 구글 GCP 그리고 마이크로소스트 Azure 등은 기업의 온-프레미스 인프라를 대상으로 한 서비스에 주력하고 있다.
온-프레미스 인프라와 퍼블릭 클라우드를 통합 운영하는 ‘하이브리드 클라우드’를 실현하는 수단으로 컨테이너 오케스트레이션 도구인 “Kubernetes”를 활용하는 것이다.

도커 CTO 퇴사

Docker 사 , Docker Enterprise 사업을 Mirantis 에 매각

IBM은 미국 시간 10 월 28 일, 오픈 소스 소프트웨어 기업 레드햇 을 340 억 달러 (약 38 조원)에 인수하기로 합의했다고 발표 했다.IBM은 주당 190 달러를 현금으로 레드햇 에 지불한다. 인수는 2019 년 하반기에 완료 될 전망이다.

웹취약점 조치 자동화

웹취약점 자동 조치

최근에 웹시스템의 취약점을 노린 공격이 증가하고 있습니다. 해커들이 웹취약점 을 통해 데이터베이스에 저장된 개인 정보나 회사 기밀자료를 외부로 유출하고 서비스에 문제를 발생시키기 때문에 기업에 심각한 문제를 초래 합니다. 자동으로 웹시스템 취약점을 조치하는 방안을 소개 합니다.

레드햇이 개발한 CRI-O 는 Kubernetes 용 Open Container Initiative (OCI) 컨테이너 런타임이다.

CRI-O : Kubernetes 를 위한 표준 컨테이너 런타임

여러분은 KUBERNETES에서 어떤 컨테이너 런타임을 사용하고 계신가요?레드햇이 개발한 CRI-O 는 Kubernetes 용 Open Container Initiative (OCI) 컨테이너 런타임이다. 특히 Kubernetes와의 통합을 염두에 두고 설계하였습니다.

Kubernetes Containerd

containerd

컨테이너 세계는 컨테이너 엔진에서 부터 레지스트리, 오케스트레이션 ,보안,네트워크,스토리지, 애플리케이션 관리까지 다양한 기술이 뒤섞여 혼란스러운 상황입니다.
2016 년 1 월에 정식 출범 한 Cloud Native Computing Foundation (이하 CNCF)는 혼돈스러운 컨테이너와 관련된 다양한 기술적인 문제들을 오픈소스로 해결하는 하는 것을 목표로하고 있습니다.

REST 애플리케이션에서 메모리 사용량 비교

Quarkus : 기존 Java 보다 10 배 가볍고 30 배 빠른 시작 시간

기존 Java 환경 보다 10 배 가볍고 30 배 빠른 시작 시간을 제공- Quarkus 는 놀랍도록 빠른 부팅 시간과 엄청나게 낮은 메모리를 사용합니다. Kubernetes 와 같은 컨테이너 오케스트레이션 플랫폼에서 즉각적인 스케일업과 고밀도로 메모리를 사용할 수 있게 합니다.

Quarkus 소개

Quarkus

Quarkus 는 Java 애플리케이션 코드에서 네이티브 바이너리를 생성하고 컨테이너화함으로써 컨테이너와 Kubernetes 환경에 최적화 된 빠르게 시작하고 메모리 소비량도 적은 애플리케이션 실행 파일을 만들수 있는 것입니다.

Tomcat 기술지원 서비스

Apache Tomcat 기술 지원 서비스

오픈나루는 고객이 안심하고 Apache 웹서버와 Tomcat 을 사용할 수 있도록 “OPENNARU Apache Tomcat Care Pack Service” 를 제공하고 있습니다.제품에 대한 기술 지원, 보안 업데이트 정보 제공, 전화/이메일/서비스데스크 지원 합니다.

IT 신기술 도입

IT 신기술에 대한 과장광고 주도형 개발 (Hype Driven Development)

IT 신기술 도입시 과장광고 주도형 개발 ( Hype Driven Development ) 의 가장 큰 문제점은 나쁜 아키텍처 결정이나 기술 스택 결정으로 몇 달 또는 몇 년 후에 팀을 괴롭히는 것입니다.결국엔 제대로 동작하지 않아서 전체를 다시 개발하는 것입니다.