hee-ya07 님의 블로그

0. 입력 값에 대한 관리0.1 제어 컴포넌트 VS 비제어 컴포넌트특성제어 컴포넌트 (Controlled Component)비제어 컴포넌트 (Uncontrolled Component)상태 관리- 상태 기반    :: React State로 관리- DOM기반    :: DOM을 직접 사용하여 관리입력값 추적- 양방향 데이터 바인딩   :: React 상태로 입력값 추적 가능- 단방향 바인딩    ::ref로 DOM에서 입력값을 직접 읽어옴성능- 상태 변화 시 리렌더링 발생- 리렌더링이 발생하지 않음복잡성- 상태 관리 코드 작성 필요- 상태 관리가 필요 없고 간단함유연성- 높은 유연성, 복잡한 폼 및 동적 입력 관리에 유리- 간단한 폼에 적합, 복잡한 유효성 검사에 불편함저장 영역- React 상태 (컴포넌..

1. Redux Middleware1.0 개념기존Middleware 사용Action -> Dispatcher -> Reducer 실행Action -> Dispatcher -> Middleware 전처리 -> Reducer 실행 -> Middleware 후처리:: 한번에 처리:: Reducer 실행에는 Only 상태 변경에 대한 역할 및 책임:: 다른 side-Effect는 Middleware에서 처리proxy 패턴과 유사1) 전처리 :: Action -> Dispatch 후 Middleware가 이후 활동을 가로채고 작업 후 다시 Dispatcher로 반환2) 후처리 :: Action을 받은 Reducer의 store처리 후, Middleware가 활동에 관여하여 작업 처리1.1 제공 파라미터// 미들웨..

0. Flux Architecture0.1 등장 배경 - MVC Architecture을 적용한 React에 대해 SSOT를 유지하기 위해 State Lifting + Props Drilling 등을 적용- 위의 적용 방법으로 인해 아래와 같은 문제점 발생1) 다량의 컴포넌트가 하나의 상태를 구독하는 경우 - 무조건 해당 상태를 가진 부모 컴포넌트의 자식이여야 함2) 상태를 사용하려는 자식 컴포넌트가 부모 컴포넌트와 매우 멀리 떨어져있는 경우 - props Drilling 발생- 이에 대한 해결을 위해 Flux Architecture가 등장 0.2 작동 원리와 구성요소:: 데이터의 흐름을 단방향으로 구성하는 아키텍처 1) Action 발생 -> 2) Dispatcher가 action 관리 및 store로..

1. Docker 명령어 분류 1.1 Docker 이미지 생성 및 관리더보기1. docker build :: Dockerfile을 기반으로 이미지를 빌드docker build -t my-image . 2. docker images :: 로컬에 저장된 Docker 이미지를 확인docker images 3. docker rmi :: Docker 이미지를 삭제docker rmi my-image 4. docker pull :: Docker Hub나 다른 레지스트리에서 이미지를 다운로드docker pull ubuntu:latest 5. docker push :: 이미지를 Docker Hub나 다른 레지스트리로 푸시docker push my-image1.2 Docker 컨테이너 실행 및 관리 더보기1. docker..

0. Dockerfile:: Docker 이미지를 만들기 위한 스크립트 (Instruction / 명령어 집합):: 각 명령어는 Docker 이미지의 하나의 레이어(Layer)로 변환:: 실행할 프로그램(앱) + 앱을 구동할 엔진 + 구동을 보조해줄 Bins/Libs 정의구성 요소1. Application 파일 (구동 코드)2. Environment Variables (환경 변수3. Runtime Environment (런타임 환경)   :: 애플리케이션을 실행하기 위한 OS나 런타임 환경(예: Java, Python 등)의 버전 및 설정을 정의4. 서드파티 라이브러리5. Cut-down OS    :: 실제로 컨테이너 내에서 실행되는 최소한의 운영 체제 (예: Alpine Linux).Ex)더보기# F..

*. 심화 내용*. 1 Docker는 왜 항상 Linux 명령어를 사용하나?더보기Docker는 기본적으로 Linux 환경에서의 컨테이너화를 목표로 설계됨=> So, Docker 자체가 Linux의 네이티브 시스템 기능을 사용하여 관리됨(Linux Containers(LXC) 기술을 기반)=> 컨테이너화를 위해 Linux의 cgroups(Control Groups)와 namespaces를 사용Namespaces:: 각 프로세스가 고유한 환경을 갖도록 분리시켜주는 기술:: 네트워크, 파일 시스템, 프로세스 등을 격리:: 프로세스별 FS, 네트워크, UID 등 영역 구별cgroups:: 시스템 자원을 격리하고 제어하는 기술:: CPU, 메모리, 네트워크, 디스크 등의 자원을 제한:: 컨트롤 그룹으로 분리 ->..

0. Docker Network:: 컨테이너 생성 시, 컨테이너는 NET namespace를 통해 구현된 가상화 기법으로 각각 독립된 네트워크 공간 할당:: 이때, 기본적으로 외부와 통신이 불가능한 상태:: 컨테이너의 포트를 노출(expose)해서 외부와 연결이 필요Docker Network는 다중 컨테이너 간의 네트워크 연결을 처리즉, Docker Compose 네트워크의 원리:: Linux의 IP Tables 기반 네트워크를 사용하여 컨테이너 연결:: 가상 브릿지 / L2 Switch(Docker0)를 중심으로==> 내부 :: 가상 / 물리 NIC 연결==> 외부 :: NAPT(Network Address Port Translation) or IP Masquerade 지원0.1 Docker0항목설명생..

1. 단일 /  다중 컨테이너:: Docker 격리 정의 시 - 단일 or 다중 이미지 구성 비교애플리케이션:: 컨테이너의 조합:: 컨테이너 = 격리된 공간에서의 프로세스가 동작하는 기술컨테이너 구성app 관리관리 주체1호스트 내 1개의 단일 컨테이너단일 이미지 구성 및 구동Dockerfile1 호스트 내 n개의 다중(멀티) 컨테이너다수 이미지 구성 및 구동Docker-Compose(하나의 YAML 파일로)1.1 Host와 Container의 관계에 따른 시스템 선택(단일 vs 다수의 호스트)시스템설명Docker- 컨테이너화 플랫폼 및 런타임- 1개의 호스트에 대한 단일 or 다중 컨테이너Kubernetes- M개의 호스트 내 N 개의 컨테이너 설정 - 여러 컨테이너 런타임에서 컨테이너를 실행 및 관리하..

0. 격리를 위한 가상화 (VM vs Container):: 환경에 따라 VM or Container로 구분구분 VM (Virtual Machine) Container 환경 정의 Guest OS + Bins/Libs + App B Bins/Libs + App B 특징 OS 레벨 독립적 애플리케이션 구동 환경 Bins/Libs 레벨 독립적 어플리케이션 구동 환경 소모 리소스 리소스 소모가 크고 느리다. 리소스 소모가 적어 가볍고 빠르다 최대  1 OS 내 3 VM 정도 ..? 1 OS 내 1000 Container 가능 컨테이너 :: 격리된 공간에서 프로세스가 동작하는 기술 (Isolated Process in Userspace) 1. Docker ?:: 컨테이너화 기술을 활용한 개발 및 배포 자..

0. 도커를 사용하는 이유Consistency - 일관성 보장Isolation - 격리Multiple Containers -  다중 컨테이너 지원0.1 일관성 보장 (Consistency)일관성:: 시스템 복제본이 있을 경우 최신의 데이터가 되도록 보장:: 현 글에서의 일관성의 의미는 개발 환경과 배포 환경에서 같은 환경이 되어야 함을 의미1. Application 파일2. Environment Variables (환경변수)3. Runtime Environment (런타임 환경, 버전)4. 서드파티 라이브러리5. Cut-down OS일관성 보장:: 다양한 로컬(인스턴스)에서도 도커로 일관된 어플리케이션 구동 가능0.2 격리(Isolation):: 로컬(인스턴스)의 환경과 분리된 도커 환경으로 로컬 환경을..