본문 바로가기
Docker #2 - 도커의 구조 도커의 구조(Docker Architecture) 도커는 _클라이언트-서버 구조_를 사용한다 도커 클라이언트는 컨테이너를 빌드, 실행 및 배포하는 등의 무거운 작업을 수행하는 도커 데몬과 통신한다 실행 위치 도커 클라이언트과 데몬은 동일한 시스템에서 실행되거나 원격의 데몬에 클라이언트를 연결할 수도 있다 통신 방식 클라이언트와 데몬은 UNIX 소켓이나 네트워크 인터페이스를 통한 _REST API_를 사용하여 통신한다. 출처 : [공식문서] https://docs.docker.com/get-started/overview/ 도커 호스트(docker host) 도커 엔진이 깔려있는 디바이스 즉, 컴퓨터 컨테이너 엔진이 컨테이너를 만들고 컨테이너를 제어 그 기능을 도커에서 만든 것이 도커 엔진 도커 데몬(doc.. 2023. 4. 5.
Docker #1 - 도커와 컨테이너, 컨테이너 이미지 도커란? 컨테이너 기반_의 _가상화 도구 리눅스 컨테이너 기술(LXC; Linux Containers) 기반 애플리케이션을 _컨테이너 단위_로 _격리_하여 실행하고 배포하는 기술 고 언어로 작성됨 공식 문서에서 말하는 도커 앱 개발, 배포 및 실행을 위한 개방형 플랫폼(open platform) 앱에서 인프라를 분리하여 신속하다 앱을 관리하는 것과 동일한 방식으로 인프라를 관리할 수 있다 앱 배포와 테스트에 있어서 도커의 방법론을 활용하면 코드 작성과 프로덕션 환경에서의 실행 사이의 지연을 크게 줄일 수 있다. 즉 도커는 다양한 운영체제에서 사용될 수 있으며 컨테이너화된 앱을 손쉽고 효율적으로 빌드, 배포, 관리할 수 있는 다양한 기능 제공해준다 [참고] 샌드박스(SandBox)란? 외부로부터 받은 파일.. 2023. 4. 5.
#6 소프트웨어 설계6 - 소프트웨어 아키텍처 소프트웨어 아키텍처 소프트웨어 아키텍처 소프트웨어 아키텍쳐 개념(Software Architecture) 개발 대상 시스템의 전반적인 구조를 체계적으로 설계 다수의 이해관계자가 참여하는 복잡한 개발에서 상호이해, 타협, 의사소통을 체계적으로 접근하기 위한 것 소프트웨어를 구성하는 컴포넌트들의 상호작용 및 관계, 각각의특성을 기반으로 컴포넌트들이 상호 유기적으로 결합하는 소프트웨어의 여러가지 원칙들의 집합 소프트웨어 아키텍처 품질 요구사항 소프트웨어의 기능, 성능, 만족도 등의 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 핵심집합 사용자의 요구사항을 얼마나 충족시키느냐에 따라 확립 ISO/IEC 9126 모델 소프트웨어 품질 특성과 평가를 위한 국제 표준 내외부 품질: 기능성(functiona.. 2023. 3. 29.
#5 소프트웨어 설계5 - UML 개념 모델링(Conceptual Modeling) 개념 모델링 요구사항을 이해하기 쉽도록 실 세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라고 함 이렇게 표현된 모델을 생성해 나가는 과정을 개념 모델링이라고 함 모델은 문제가 발생하는 상황에 대한 이해를 증진하고 해결책을 설명하므로 소프트웨어 요구사항 분석의 핵심이라고 할 수 있음 개발 대상 도메인의 엔티티(Entity)들과 그들의 관계 및 종속성을 반영 요구사항별로 관점이 다르므로 개념 모델도 다양하게 표현되어야 함 대부분 UML(Unified Modeling Language)을 사용 개념 모델링의 종류 Use Case Diagram Data Flow Model State Model Goal-Based Model User Interactions.. 2023. 3. 26.
#4 소프트웨어설계4 - 요구사항 개발 요구사항 개발 요구공학(Requirements Engineering) 소프트웨어 개발 시 사용자 요구가 정확히 반영된 시스템 개발을 위하여 사용자의 요구를 추출, 분석, 명세, 검증, 관리하는 구조화된 활동 집합 요구사항을 정의하고, 문서로 만들고, 관리하는 프로세스를 의미 효과적인 의사소통을 통하여 공통 이해 설정, 불필요한 비용절감, 요구사항 변경 추적 가능 분석 결과의 문서화 자료 흐름도, 자료 사전 등이 효과적으로 이용될 수 있으며, 더 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용될 수 있음 요구공학의 목적 이해관계자 사이의 원활한 의사소통 수단 제공 요구사항 누락 방지, 상호 이해 오류 등 제거로 경제성 제공 요구사항 변경 이력 관리를 통하여 개발 비용 및 시간 절약 비용과 일.. 2023. 3. 25.
#3 소프트웨어 설계 - 현행 시스템 분석 현행 시스템 분석 현행 시스템 분석 현행 시스템 분석의 정의와 목적 현 시스템이 어떤 하위 시스템으로 구성되어 있는 지 파악하는 절차 현행 시스템의 제공 기능과 타 시스템과의 정보 교환 분석을 파악 현행 시스템의 기술 요소와 소프트웨어, 하드웨어를 파악 목적: 개발 시스템의 개발 범위를 확인하고 이행 방향성을 설정 현행 시스템 파악 절차 [1단계] [시스템 구성 파악] --> [시스템 기능 파악] --> [시스템 인터페이스 현황 파악] [2단계] [아키텍처 파악]--> [S/W 구성 파악] [3단계] [시스템 H/W 현황 파악]--> [네트워크 구성 파악] 시스템 아키텍처 상위 시스템과 하위 시스템들이 어떤 관계로 상호작용하는 지 각각의 동작 원리와 구성을 표현 단위 업무 시스템별로 아키텍처가 다른 경우.. 2023. 3. 24.
#2 소프트웨어 설계 - 애자일과 스크럼 애자일(Agile) 개발 방법론 애자일 방법론 날렵한, 재빠른이란 사전적 의미 특정 방법론이 아닌 소프트웨어를 빠르고 낭비없이 제작하기 위해 고객과의 협업에 초점을 두고 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항 수용 가능 특징 짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화 종류 익스트림 프로그래밍(XP, eXtremProgramming) 스크럼(SCRUM) 린(Lean) DSDM(Dynamic System Development Method) FDD(Featrue Driven Development) Crystal ASD(Adaptive Software Development, 적응형 소프트웨어 개발 방법론) DAD(Disciplined Agile.. 2023. 3. 23.
#1 소프트웨어 설계 소프트웨어 공학의 개념 소프트웨어 소프트 웨어의 개념 컴퓨터를 동작시키고 어떤 일의 처리 순서와 방법을 지시하는 명령어의 집합인 프로그램_과 프로그램의 수행에 필요한 _절차, 규칙, 관련 문서 등을 총칭 프로그램 컴퓨터를 통해 일련의 작업을 처리하기 위한 명령어와 관련된 데이터의 집합 자료구조(Data Structure) 컴퓨터 기억 장치 내에 자료의 표현, 처리, 저장 방법 등을 총칭하는 것으로 데이터 간의 논리적 관계나 처리 알고리즘을 의미함 문서(paper) 소프트 웨어를 개발함에 있어서 사용자 설명서, 소프트웨어 요구분석서, 평가서, 명세서, 프로젝트 계획서, 검사 계획서 등을 의미함 소프트웨어 특징 상품성 소프트 웨어를 개발하면 상품이 되어 판매가 됨 복잡성 개발하는 과정이 복잡하고 관리가 어려.. 2023. 3. 21.
HTTP 의미 체계 준수 HTTP 의미 체계 준수 HTTP 사양을 준수하는 API 디자인에 대한 일반 고려 사항을 알아보자 미디어 유형 클라이언트와 서버는 Resource Representation을 교환함 POST 요청의 경우 요청 본문에 생성할 Resource의 Representation이 포함됨 GET 요청의 경우 응답 본문에 가져온 Resource의 표현이 포함됨 HTTP 프로토콜에서의 표현 형식 HTTP 프로토콜에서 형식은 MIME 유형이라고 하는 _미디어 유형_을 사용하여 지정됨 이진이 아닌 데이터의 경우 대부분의 Web API는 JSON과 XML을 지원함 JSON 미디어 유형: application/json XML 미디어 유형: application/xml 미디어 유형 지정 요청 / 응답의 Content-Type 헤.. 2023. 3. 13.

티스토리툴바