JPA란? > Standard API for Object-to-Relational Mapping (ORM) 모든 저수준(low-level) SQL 처리 개발자들이 객체 모델을 사용하여 프로그래밍에 집중할 수 있도록 도움 !Object-To-Relational Mapping (ORM) 단순 명세 인터페이스 집합을 정의함 사용하기 위해서 구현이 필요함 표준 API를 사용함으로써, 공급자의 구현에 얽매이지 않음 ※ JPA는 구현이 없는 명세나 인터페이스임 ※ Hibernate는 JPA의 구현체임 JDBC vs JPA(Hibernate) vs Spring Data JPA !JPA JDBC: Low-Level Database Access JPA: Java Persistence API를 나타내는 기술적 명세, 관계형 데이터베이스를 위한 인터페이스로 정의됨 Hibernate: JPA의 구현체 Spring Data JPA: JPA를 쉽게 하용하도록 만든 모듈 !JPA Entity Class > 데이터베이스 테이블에 매핑되는 자바 클래스 !Entity Class 최소 조건 @Entity 주석 필수 public 혹은 protected 기본 생성자 필수 (다른 생성자도 가질 수 있음) Java Annotations 1단계: 클래스를 데이터베이스 테이블에 매핑하기 2단계: 필드를 데이터베이스 컬럼에 매핑하기 @Table !Map class to database table 선택사항으로 없으면 클래스 이름으로 자동 설정됨 @Column !Map fields to database columns 선택사항으로 없으면 필드 이름으로 자동 설정됨 @Id, @GeneratedValue Primary Key !Primary Key 각 행을 고유하게 실벽 반드시 고유한 값으로 NULL일 수 없음 ID Generation Strategies | 타입 | 설명 | | | | | GenerationType.Auto | 특정 데이터베이스를 위한 적절한 전략을 선택 | | GenerationType.IDENTITY | 데이터베이스 ID 열을 사용하여 Primary Key 할당 | | GenerationType.SEQUENCE | 데이터베이스 시퀀스로 Primary Key 할당 | | GenerationType.TABLE | 기본 키의 고유성을 보장하기 위해 기본 데이터베이스 테이블을 사용하여 할당 | Entity Manager !Entity Manager EntityManagerFactory : EntityManager의 객체 제공 JPA EntityManager (interface) : 특정 애플리케이션에서 데이터베이스를 접근하기 위해 사용 > EntityManager API는 영속적인 엔티티 인스턴스를 생성 및 제거하고, 기본 키로 엔티티를 찾으며, 엔티티를 대상으로 쿼리를 수행하는 데 사용됩니다. | Action | JPA Methods | Hibernate Methods | | | | | | Create/Save new Entity | entityManager.persist(...) | session.save(...) | | Retrieve Entity by ID | entityManager.find(...) | session.get(...)/load(...)| | Retrieve list of Entities | entityManager.createQuery(...) | session.createQuery(...) | | Save or Update Entity | entityManager.merge(...) | session.saveOrUpdate(...) | | Delete Entity | entityManager.remove(...) | session.delete(...) | Persistence Contetxt !Persistence Contetxt EntityManager 객체는 Persistence Context와 연관된다. Persistence Context는 Entity 객체들의 집합으로 데이터베이스에서 엔티티를 가져오거나 데이터베이스에 저장할 때 사용되는 1차 캐시 Entity Lifecycle !Entity Lifecycle | 상태 | Persistence Context에 있음? | 설명 | ||-|-| | New / Transient | ❌ 아님 | 아직 저장되지 않은 순수 객체 | | Persistent / Managed | ✅ 있음 | Persistence Context가 관리 중 | | Detached | ❌ 아님 | 한 번 저장됐지만 지금은 관리되지 않음 | | Removed | ✅ 있음 (삭제 대기 상태) | 삭제 예약된 상태. flush/commit 시 실제 삭제 | EntityManager API > CRUD (Create, Read, Update, Delete) ※ EntityClass와 Primary Key 전달 > 복잡한 연산은 어떻게 할까? JPA Query Language (JPQL) 객체들을 조회하기 위한 Query Language SQL과 비슷하지만 JPQL은 entity name과 entity fields에 기반함 ※ Class 이름과 Return 타입 전달 ※ 엔티티 이름 필드 이름에 주의가 필요함 ※ Query에 변수 사용 시 parameter를 설정해주어야 함 DAO (Data Access Object) 데이터베이스를 규격화 함 JPA Entity Manager가 필요함 (조회, 저장을 위한 기본 컴포넌트) !Data Access Object JPA Entity Manager JPA Entity Manager는 데이터 소스가 필요함 데이터 소스는 데이터베이스 연결 정보를 정의함 JPA Entity Manager를 Student DAO에 자동 주입하거나 주입할 수 있음 Spring @Transactional 자동으로 JPA 코드에 대한 트랜잭션을 시작하고 종료함 코드를 명시적으로 작성할 필요가 없음 사용자 모르게 처리됨

Web Basics Request Parameter란 사용자가 발행한 HTTP 요청 메시지의 일부분으로 전송됨 두가지 전송 방식이 있음 Query string (GET Method) HTTP entity body (POST Method) !GET !POST Data Binding > 요청 파라미터에서 해당하는 객체로 어떻게 이동할 것인가? Naive solution @RequestParam annotation을 사용하여 requset parameter와 method parameter를 바인딩 할 수 있다. Spring Data Binding 요청 파라미터를 form bean에 바인딩하는 과정으로, form에서 오는 데이터는 자동으로 객체에 바인딩 될 수 있음 > 함수 파라미터에 객체를 선언하기만 하면 됨 다음과 같은 작업들이 발생함 새로운 form bean 인스턴스화됨 form bean은 요청 파라미터로부터 채워짐 form bean은 모델에 추가됨 !Data Binding offer form bean은 모델에 자동적으로 추가됨 form bean은 모델 속성 !Data Binding 뷰에서도 접근, form bean을 랜더링할 수 있다. Data Validation > 유저는 실수를 할 수 있다 그렇기에 에러를 설명하거나 유저가 이를 해결할 수 있도록 하고 싶다. Hibernate Validator 사용자의 에러를 검출하기 위해, 폼 빈에 캡슐화된 폼 데이터를 검증해야함 Bean Validation API (JSR-303)는 JavaBean 검증을 위한 API를 정의하는 명세입니다. 폼 빈 속성에 선언적 검증 제약 조건을 주석으로 달 수 있습니다. (`@NotNull`, `@Pattern`, `@Size`) Hibernate Validator는 몇가지 커스텀 annotation을 제공 (`@Email`) Message Interpolation > 위반된 Bean Validation 제약 조건에 대해 오류 메시지를 생성하는 것 !Message Interpolation > 각 속성의 message descriptor를 메시지 속성을 통해 정의할 수 있습니다 Validating Object 검증은 @Valid 어노테이션을 통해 이루어짐 @Valid 어노테이션은 객체가 먼저 검증된 후 모델에 추가되도록 함 핸들러 메서드는 검증 과정의 결과를 나타내는 BindingResult 객체 요청 가능 가능한 검증 오류를 확인하기 위해 BindingResult 객체 검사 가능 Data Buffering > 사용자가 필수 입력 사항을 잊었을 때 처음부터 다시 입력해야하는가? Spring form tag library 해당 내용을 웹 폼에 바인딩해야 함 Spring은 미리 채워진 폼 빈을 처리하기 위해 데이터 바인딩을 지원하는 태그 세트를 제공함 !Spring form tag library 해당 라이브러리 사용을 위해 JSP 페이지 최상단에 아래를 추가해야함 | Spring form tag lib | HTML | | | | | `` | `` | | `` | `` | | `` | `` | | `` | `` | Revised JSP 다음은 앞선 라이브러리를 사용한 코드이다 Revised Controller !initial Web Form !Web Form on Error Error Messages > 사용자에게 데이터가 거부된 이류를 알려주어야 함수 !Error Messages 이를 위해, BindingResult 객체는 자동으로 모델에 삽입되어 뷰로 다시 전송함 Spring MVC는 Spring의 폼 태그 라이브러리의 일환으로 `` 태그 제공. `` 태그는 BindingResult 객체에서 가져온 HTML 오류 메시지를 렌더링합니다. Summary 폼 빈(Form beans)은 여러 역할을 동시에 수행할 수 있는 다재다능한 객체 데이터 바인더(Data binder): 폼 데이터를 Java 객체에 바인딩하는 역할 데이터 검증기(Data validator): 폼 데이터의 유효성을 검사하고 검증하는 역할 데이터 버퍼(Data buffer): 폼 데이터가 임시로 저장되거나 관리되는 역할

MVC Pattern 스프링은 프레임워크는 MVC 아키텍쳐를 제공한다 Model 데이터 캡슐화, POJO로 구성됨 View model 데이터를 랜더링, 대체로 HTML 형식 Controller 사용자 요청 처리, 적절한 모델을 만들고 view 랜더링을 위해 넘겨줌 !MVC 패턴 Dispatcher Servlet 프론트 컨트롤러 역할 모든 요청을 가로채고 핸들러(컨트롤러)로 전달 요청을 처리할 컨트롤러를 호출하기 위해 핸들러 매핑을 참조 Handler Mapping 특정 요청을 처리할 적합한 컨트롤러를 찾는 역할 요청 URL과 컨트롤러 클래스 간의 매핑은 XML 설정, 애노테이션을 통해 수행 Controller 요청을 처리하며 비즈니스 로직 호출 출력은 모델 객체에 첨부되어 뷰로 전달 View Resolver 논리적 이름으로부터 실제 뷰 파일을 찾는 역할 View JSP, HTML ... 같은 실제 뷰 파일을 의미 Required Configuration Maven Configuration POM.xml Web deployment descriptor Web.xml Spring MVC Configuration `root-context.xml`, `servlet-context.xml`, `dao-context.xml`, `service-context.xml` Maven Configuration > 각종 라이브러리의 의존성 선언 !POM.xml Web deployment descriptor DispatcherServlet Spring 컨테이너(WebApplicationContext) 인스턴스화 다른 DI 컨테이너와 마찬가지로, WebApplicationContext는 일부 구성 메타데이터를 제공받아야 함 !DispatcherServlet ContextLoadListener 공유 Beans가 포함된 Spring Container 인스턴스화 DispatcherServlet에 의해 생성된 Beans은 ContextLoaderListener에 의해 생성된 Beans를 참조할 수 있음 (DispatcherServlet's Beans → ContextLoaderListener's Beans) Spring MVC Configuration `root-context.xml` 파일이 Spring 애플리케이션의 루트 컨테이너 설정을 담당하며, 기본적으로 비어 있지만 애플리케이션 시작 시 자동(`ContextLoaderListener`) 으로 로드된다 `servlet-context.xml` `DispatcherServlet에 의해 로딩됨 `` 프레임워크에 패키지 내 파일 스캔을 annotation based로 수행할 것임을 알림 `` 정적 메소드는 GET 요청으로 바로 접근할 수 있도록 매핑 Bean `InternalResourceViewResolver` 물리 JSP 파일들을 논리 이름으로 어떻게 찾을 수 있는지 알려줌 `` Spring Container에게 annotation based 사용시 어떤 패키지가 스캔될지 알려줌 Model 모델은 결과의 일부를 포함하며 객체를 컨트롤로에서 뷰로 전달할 때 사용된다. 이는 명명된 객체의 모음이다. | Key(name) | Value | | | | | key1 | value1 | | key2 | value2 | | key3 | value3 | > 각 행은 named object 혹은 model attributes 로 불림 !Model 모델 구현 방법은 세 가지로 나눌 수 있다. Map java.util.Map Model Spring 에서 제공하는 Model interface 구현하여 사용된다 Model에서는 key 값을 지정해줄 필요가 없음 모델을 채우기 위한 편리한 방법 제공됨 (addAttribute()) key 값을 자동 혹은 수동으로 지정할 수 있음 ModelMap Spring에서 제공되는 객체로 더 편리함을 제공 (chained calls) Controller > @Controller 어노테이션이 붙은 빈(bean) @Controller 어노테이션 컨트롤러 역할을 한다는 것을 나타냄 @RequestMapping 어노테이션 URL ↔︎ 전체 클리스, 특정 핸들러 메소드 매핑 Class level mapping Handelr level mapping Example Add attributes to the model Retrieve request parameters as regular parameters > http://localhost:8080/spring/login?username=scott&password=tiger JSTL JSP는 Java Server Pages의 약자로, 동적인 웹 페이지를 생성하는 데 사용되는 기술 prefix “c” can be used for core language prefix “fn” for using JSTL functions

의존성이란? 이러한 경우 PetOwner는 AnimalType에 의존하게 된다. 하지만 이러한 구조에는 문제가 있는데 다음과 같다. PetOwner 객체가 AnimalType 객체 생성을 관리하기 때문에 두 객체 사이의 Tight Coupling이 발생한다. > 따라서 AnimalType 객체의 변경은 PetOwner의 변경을 야기한다 의존성 주입 (Dependency Injection) 앞선 문제점은 DI를 통해 해결할 수 있다. !DI Bean Container는 Bean을 생성하고, 의존성 주입을 수행한다. 의존성 주입도 제어의 역전(IoC)의 한 종류이다. 따라서 코드는 다음과 같이 변화할 수 있다. > 따라서 의존성 주입(DI)는 객체가 자신의 의존성을 직접 처리하는 것이 아니라, 프레임워크에 의해 의존성이 주입되는 디자인 패턴이다. 이 패턴은 프레임워크에 의해 동적으로 주입되기 때문에 여러 객체 간의 결합도를 줄여준다. Spring (IoC) Container 스프링 프레임워크의 코어 컴포넌트로 객체 생성 관리, 객체 의존성 주입의 주요 기능을 갖고 있다. Spring Container의 구성하는 방법 세 가지 xml Java annotation Java-based Configuration Spring Container의 종류 두 가지 BeanFactory ApplicationContext | BeanFactory | ApplicationContext | | - | - | | 매우 간단, 주로 DI를 위함 | 더 확장, 고급 기능 제공 | | 리소스가 제한된 경우 사용 (모바일...) | 아래 특징을 가진 어느곳애서든 사용 1. 엔터프라이즈 인식 기능2. 애플리케이션 이벤트를 리스너에 게시3. 요청 시 빈을 연결하고 폐기 | | org.springframework.beans.factory.BeanFactory | org.springframework.context.ApplicationContext | | XMLBeanFactory | ClassPathXmlApplicationContext | 전체 플로우 !Spring Container and DI main 함수에서 ApplicationContext 객체 생성 Spring Container가 Bean 생성 의존성 주입 수행 Advantages of DI 의존성을 낮추어 코드 변경 줄어듦 코드 재사용성 증가 테스트 용이 (mock implements를 주입시키면 되기 때문에) 코드 가독성 증가 Bean이란? 스프링에서 POJO 클래스를 Bean이라고 부름 Configuration metadata를 통해 Spring Container에 의해 생성되고 관리됨 getBean() 메서드로 객체에 접근할 수 있음 Spring Bean Definition | Key | 역할 | | - | - | | class (required) | 클래스 네임 구분 | | id | bean을 구분하는 식별자 | | scope | 객체의 범위 (singletone, prototype) | | constructor-arg | 객체 생성 시 넘겨줄 매개변수 | | property | 생성 시 setter에 넘겨줄 매개변수 | | init, destory | 함수 | Spring Annotation Based Configuration Spring 2.5 이후에 개발되어 유명해짐 XML의 구성은 방대해질 수 있음 Default가 아니기에 설정이 필요 빈 설정에서 XML이 어노테이션을 덮어쓴다 (XML이 우선순위가 더 높음) @Required Setter 메소드에서만 가능 @Autowired ⭐️ xml 방식 Annotation 방식 @Qualifier > @Autowired가 타입 모호성을 가질 때 사용 @Resource @Resource는 xml의 id(name)로 구분 @Autowired는 클래스로 구분 다만 작동 방식은 동일함 결론 POJO는 "Plain Old Java Object"로, 복잡한 구조나 규약 없이 간단한 Java 객체를 의미 빈(Bean)은 Spring에서 관리하는 객체로, Spring 컨테이너가 생성하고 관리 제어의 역전(Inversion of Control)은 객체의 생성과 생명 주기를 Spring 컨테이너가 관리하게 하는 디자인 패턴 의존성 주입(Dependency Injection, DI)은 객체 간의 의존성을 외부에서 주입하여, 객체들이 서로 독립적으로 동작(의존성을 낮춤)할 수 있도록 도와줍니다.

사전지식 웹 시스템 - 웹에서 서로 다른 호스트의 상호 작용을 위한 소프트웨어 시스템 클라이언트-서버 기반 HTTP, 메시지 지향적(xml,json) 플랫폼 중립적, 독립적 프레임워크 소프트웨어 품질에는 기능 품질, 구조 품질이 있다. 프레임워크란 구조 품질을 보장한다. 프레임워크는 반제품으로 애플리케이션 구조 및 코드의 상당 부분을 제공, 개발자는 핵심 로직 개발에 집중 가능하다. 이를 통해 높은 생산성과 코드 품질이 보장된다. 라이브러리 ↔ 프레임워크 중요한 차이점은 제어의 역전 (Inversion of Controll)이다. | | 라이브러리 | 프레임워크 | | | - | - | | 차이 | 제어의 주체: 개발자(호출)클래스의 집합: 코드 재사용 ↑ | 제어의 주체 : 프레임워크 (IoC) 프레임워크의 구조에 따라 코드 작성하면 프레임워크에서 호출 | 스프링이란? > Light weight JavaApplication Framework POJO 기반의 앤터프라이즈 애플리케이션 개발을 쉽고 편하게 함 자바 애플리케이션을 개발하는데 필요한 하부구조 (infrastructure)를 포괄적으로 제공 스프링이 하부 구조를 처리하므로 개발자는 애플리케이션 개발에 집중 스프링의 주요 특징 의존 관계 주입 (Dependency Injection) 관점 중심 프로그래밍 (Aspect Oriented Programming) 이식 가능한 서비스 추상화 (Portable Service Abstraction) DI 객체간의 의존성을 낮추기 위함 객체와 그 의존성을 직접 생성하는 대신, 외부 엔티티(즉, Spring IoC Container)에 의해 객체가 생성 및 구성된다 PersonService는 Person에 의존한다 Spring Container에 의해 생성된 Person 객체는 생성자를 통해 주입된다. AOP 애플리케이션의 핵심 비즈니스 로직과 공통적으로 필요한 부가 기능(예: 로깅, 보안, 트랜잭션 관리 등)을 분리하여 모듈화하는 프로그래밍 패러다임 관심사의 분리: 비즈니스 로직과 부가 기능을 분리하여 각각의 역할을 명확히 함 재사용성 증가, 유지보수 용이 > 비즈니스 로직과 로깅 로직 혼재 > Aspect (LoggingAspect) 로깅 기능을 별도의 클래스로 분리하여 관리 PSA 애플리케이션 코드가 다양한 서비스 제공자와 상호작용할 수 있도록 공통 인터페이스를 제공하는 추상화 계층 공통 인터페이스 제공: PSA 계층은 여러 서비스 제공자(구체적인 서비스 구현체)와 애플리케이션 코드 사이에 일관된 인터페이스를 제공. 애플리케이션 코드는 이 공통 인터페이스를 통해 서비스와 상호작용하므로, 개별 서비스 제공자의 세부 구현에 신경 쓸 필요가 없음 유연한 서비스 전환: PSA를 사용하면 서비스 제공자를 변경할 때 애플리케이션 코드를 수정할 필요 없이 PSA 계층이 제공하는 인터페이스만 준수하면 됩니다. 이로 인해 서로 다른 서비스 제공자 간의 전환이 매우 용이해짐. Spring과의 통합: Spring 환경에서 PSA를 도입하면, 의존성 주입 등과 같은 Spring의 기능을 활용하여 PSA 계층을 관리할 수 있고, 이를 통해 보다 모듈화된 설계와 유지보수가 용이한 코드를 작성 가능. 결론 스프링을 통해 Java Enterprise 시스템 개발이 용이 비즈니스 로직에 집중 가능하여 생산성 증대 재사용 및 유지 보수 용이, 확장성을 가진 코드 설계

들어가며 내가 설계한 기본적인 프로세스는 다음과 같다 `메인 브랜치로 머지` → `Webhook 전달` → `Docker 이미지 빌드` → `Docker Hub에 푸시` → `결과 알림` 본 글에서 Discord 알림을 제외한 모든 프로세스를 다룰 것이다. Jenkins 접속 브라우저에서 ec2 public ip에 8080 포트로 jenkins 서버에 접속한다. > 예시) http://0.0.0.0:8080 > 명령어를 통해 출력된 admin 비밀번호로 로그인이 가능하다. Install suggeseted plugins 설치 로그인 계정을 생성하고 젠킨스 접근 URL을 입력한다 Credentials 생성 GitHub Credentails GitHub Access Token 발급 `Settings` > `Developer Settings` > `Personal access tokens (classic)` > `Generate new token (classic)` repo 관련 권한과 hook 권한을 체크해준다. GitHub Credentails 등록 `jenkins 관리` > `Credentials` > `System` > `Glabal credentials` > `Add Credentials` Kind: Username with password Scope: Global Username: GitHub username Password: GitHub access token ID: Identifier used in pipeline code (e.g., github-credentials) Docker Credentails Kind: Username with password Scope: Global Username: Docker Email Password: Docker Password ID: Identifier used in pipeline code (e.g., github-credentials) plugins 다운로드 > GitHub API Plugin > Generic Integration > Generic Webhook Trigger > SSH Agent Plugin > Docker > Docker Pipeline | | | | | | GitHub Webhook 설정 `Settings` > `Webhooks` > `Add webhook` > Payload URL 예시 - http://0.0.0.0:8080/github-webhook/ (jenkins 주소) Pipeline 구축 `new items` > `pipeline` | | | | | - | > 사진과 같이 선택하고 GitHub 레포지토리 URL을 넣으면 된다. 결과 확인 | | | | - | - | > main 브랜치에 머지되면 이미지 빌드를 수행하고 Docker Hub에 업로드 되는 것을 볼 수 있다.

들어가며 캡스톤 디자인 기획, 설걔 단계에서 아키텍쳐 설계 부분을 담당하게 됐다. 지난 2학기에 진행했던 프리캡스톤의 기억을 더듬어보니 EC2 서버에 볼륨이 부족하여 자주 Docker 빌드가 실패하던 악몽이 떠올랐다. 그래서 이번 캡스톤 디자인에서는 Docker 이미지를 운영 서버에서 Build하지 않도록 설계하고자 하였다. !아키텍쳐 내가 설계한 기본적인 프로세스는 다음과 같다 `메인 브랜치로 머지` → `Webhook 전달` → `Docker 이미지 빌드` → `Docker Hub에 푸시` → `결과 알림` EC2 인스턴스 정보 os: Amazon Linux 2023 AMI instance: t2.micro volumn: 30GB Jenkins 설치 Jenkins 저장소 등록 wget 명령어를 사용하여 Jenkins의 yum 저장소 파일을 다운로드합니다. 이를 통해 yum이나 dnf 패키지 관리자가 Jenkins 패키지를 찾을 수 있게 됩니다. Jenkins GPG 키 가져오기 Jenkins 저장소에서 제공하는 GPG 키를 가져와 시스템에 등록합니다. 이 키는 패키지의 무결성과 신뢰성을 확인하기 위해 사용됩니다. Amazon Corretto JDK 17 설치 Jenkins 설치 Jenkins 서비스 부팅 시 자동 시작 설정 Jenkins 서비스 시작 Jenkins 서비스 상태 확인 Git 설치 설치 및 버전 확인 Docker 설치 도커 설치 도커 실행 및 활성화 jenkins 사용자를 도커 그룹에 추가 jenkins 재시작 jenkins 접속 확인 브라우저에서 ec2 public ip에 8080 포트로 jenkins 서버에 접속한다. > 예시) http://0.0.0.0:8080 !접속 성공 🦄

build.gradle 의존성 추가 application.yml 파일 수정 하단에 해당 부분을 추가하여준다. SwaggerConfig 클래스 생성 !접속 성공

패키지 설치 설치 가능한 mariadb 패키지 검색 Mariadb 설치 Mariadb 실행 Mariadb root 비밀번호 설정 로그인 확인 그 외 설정 Docker 이미지 다운로드 DB 생성 및 사용자 설정 SpringBoot 프로젝트 설정 build.gradle 의존성 추가 application.yml, application-local.yml 파일 생성 src/main/resources/application.yml src/main/resources/application-local.yml docker-compose.yml 수정 !🔥 dbeaver 접속 성공

Docker란? Docker는 애플리케이션을 실행할 수 있는 가벼운 가상화 환경인 컨테이너를 생성하는 도구이다. 컨테이너는 시스템의 전체 운영체제를 복제하는 대신, 필요한 부분만 분리하여 애플리케이션을 격리된 환경에서 실행할 수 있게 한다. 이를 통해 개발 환경과 배포 환경의 일관성을 유지하고, 리소스를 효율적으로 사용할 수 있다. Docker는 개별 컨테이너를 만들고 실행하는 데 사용되며, 주로 하나의 애플리케이션 또는 서비스를 컨테이너화할 때 활용된다. 반면에 Docker Compose는 여러 컨테이너를 정의하고 관리할 수 있는 도구로, 복잡한 애플리케이션에서 여러 서비스(예: 웹 서버, 데이터베이스 등)를 한 번에 설정하고 실행할 수 있도록 도와준다. Docker Compose를 사용하면 docker-compose.yml 파일에서 설정을 정의하고, 한 명령어로 여러 컨테이너를 일괄적으로 관리할 수 있다. Docker 설치 방법 yum update install docker service docker grant permission to ec2-user Docker service start and enable automatic startup Docker-compose 설치 방법 yum에는 기본적으로 Docker Compose 패키지가 없기 때문에, 직접 바이너리를 다운로드하여 설치해야 한다. Docker-compose 바이너리 파일 다운로드 실행 권한 부여 설치 확인 !설치 성공 ✨

들어가며 교내 팀 프로젝트를 통해 백엔드 개발 다수 존재하지만, 환경 구축이나 배포 경험은 부족하다. 이번 학기에는 "다우기술"의 사내 문제를 해결하는 해커톤 형태의 과목을 수강하게 되었고, 팀원들과 역할을 분담하여 초기 백엔드 환경 구축 및 배포를 맡게 되었다. AWS란? AWS(Amazon Web Services)는 클라우드 컴퓨팅을 통해 다양한 서비스를 제공하는 플랫폼으로, 전 세계적으로 사용되는 안전하고 확장 가능한 인프라를 제공한다. 이를 통해 사용자는 서버 자원을 유연하게 조정하고 관리할 수 있으며, 초기 비용 없이 필요한 만큼만 비용을 지불할 수 있다. 본 글에서는 EC2를 사용하여 진행할 것이다. EC2 인스턴스 생성 및 설정 보안 규칙은 다음과 같이 설정해둔다 !보안 규칙 EC2 Instance Console에 접속 인스턴스 생성 시 발급 받은 pem 키가 있을 것이다. 해당 명령어로 권한을 변경하여 준다. !접속 성공 🤩