# Travis CI

99_insung

https://docs.travis-ci.com/user/job-lifecycle/#deploying-your-code 왜 before_deploy 블럭이 두번실행되는지 gpt한테 아무리 물어도 모르더라.. 그래서 공식문서를 확인해보니 provider가 두 블럭이나 있어서 before_deploy도 두번 실행된 것... 이게 어디서 문제엿냐면 쉘스크립트

99_insung

이전에 Travis CI + S3 + CodeDeploy 를 통해 스프링부트 프로젝트를 EC2 인스턴스에 배포하는 과정까지 진행하였다. 나는 도커를 통한 배포를 원해서 구글링을 해보긴 했는데, 대부분 으로 내가 원하는 과정이 아니었다.. > 참고를 많이 했던 블로그 https://devlog-wjdrbs96.tistory.com/317 🐳🔧도커 허브 + Travis CI **내가 원한 방식은 도커허브를 같이 이용하는 방법이었음. 그래서 생각한 방법은 시키는 동작으로 워크플로우를 작성해보기로 하였다.** > ![](https://velog.velcdn.com/images/99_insung/post/6b978fab-04c9-48e3-b392-e6a0d5d57bc4/image

jinony

문제 상황❗️ > 💡 백엔드 서버 개발이 어느정도 완료된 이후, 나는 CI/CD를 통한 배포 자동화를 구축하려고 했다. 서버 개발이 완료되지 않았는데도 왜? > 비즈니스 코드가 변경되면 매번 다시 빌드하고.. 원격 서버의 서버를 중지하고.. .jar 파일을 원격 서버에 옮기고.. 기다리고.. > 이러한 일련의 과정들이 너무 귀찮고, 사용하는 입장에서도 만약 트래픽이나 사용량이 많다고 하면 사용자들이 불편을 느낄 것이라고 생각했다. 따라서, 백엔드 서버 개발이 마무리 되지는 않았지만, CI/CD를 구축해보자! 라는 생각과 함께 스크립트를 짜보기 시작했다. > 우선, 어떤 서비스를 사용할까? > Github Action Jenkins Travis CI 후보는 위 세 서비스를 고려했다. 하지만, Travis CI는 유료이고, Jenkins는 CI/C

hanhae

프로젝트를 진행하면서 발생했던 이슈와 이러한 이슈를 어떻게 해결했는지 시리즈로 만들어 작성하려고 한다. master 브랜치에 푸시되면 Travis CI가 자동으로 빌드 및 테스트 후 EC2에 배포되도록 했다. application.yml 파일에는 외부에 노출되어서는 안될 주요 정보가 포함되어있다. 따라서 github에 yml 파일을 그대로 올려서는 안된다. 그렇다면 어떻게 EC2에 yml 파일을 전달할까? 암호화한 yml 파일을 github에 올리면 Travis CI가 파일을 복호화한 뒤 빌드하도록 한다. 따라서 yml 파일이 외부에 노출되지 않고 EC2에 전달된다. 먼저 로컬에서 travis-cli를 설치 후 로그인한다. 참고로 github 계정으로 로그인하려면 개인적인 접근 토큰이 필요하다. 따라서 github의 Settings > Developer settings > Personal access token에서 토큰을 생성하자. 로그인에 성공했으면 travis

iseon_u

CH09 - Travis CI 배포 자동화 CI & CD CI Countinuous Integration 지속적 통합 코드 버전 관리하는 시스템에 PUSH 되면 자동으로 테스트와 빌드 수행 안정적인 배포 파일을 만드는 과정 CD Countinuous Deployment 지속적인 배포 빌드 결과를 자동으로 운영 서버에 무중단 배포를 진행하는 과정 CI 4가지 규칙 모든 소스 코드가 현재 실행되고 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것 빌드 프로세스를 자동화 - 시스템 빌드 단일 명령어 사용 테스팅 자동화 - 테스트 단일 명령어 사용 현재 실행 파일 - 완전한 실행 파일에 대한 확신 Travis CI 연동 Home – Travis-CI > .travis.yml > branches Travis CI 를

daydream

7월 말쯤에 CI/CD 구축 후 오랜만에 Travis CI 홈페이지에 방문해 보니 뭔가 빨간 게 보인다. 문제 잔액 부족으로 비활성 되었다는데 혼란스럽다. 공식 문서를 찾아보자. Billing FAQ - Travis CI 해결 과정 <img src="https://velog.velcdn.com/images/daydream/post/49

soohyeonb_9

문제 상황 Travis CI와 연동하는 중 이런 에러가 travis 에서 발생했다 자세한 과정 intelliJ에서 yml 파일을 작성하고 github에 푸시했었다 근데 travis plan이랑 이메일을 컨펌하지 않은 상태였어서 이전에 push 한게 적용이 안됐다 그래서 plan 선택하고 이메일 컨펌도 했다 근데 travis 보드에 push가 none으로 아무것도 안떠서 yml 파일에 스페이스 하나만 새로 넣어서 다시 깃헙에 푸시했다 그랬더니 travis에서 이런 오류를 보냄! 해결 1 - yml 파일에서 모두에게 접근권한 부여하기 첨부한 사진 208번째 줄을 보면 permission denied라는 log가 뜬다 모든 사용자에게 접근권한을

mirumi

책을 읽으면서 공부한 내용입니다. 책 제목: 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 9장에서 배운 내용 (책 368쪽) > 9-1. CI / CD에 대한 소개 9-2. 깃허브의 무료 CI 서비스인 Travis CI에 대한 소개와 프로젝트 연동 방법 9-3. AWS의 CD 서비스인 CodeDeploy에 대한 소개와 프로젝트 연동 방법 9-4. 수동 배포 방식에서 자동화 방식으로의 개선 9-5. CodeDeploy에서 오류 로그를 보는 방법 8장까지의 내용으로는 개발자가 스크립트를 직접 실행해야 했다. Test & Build가 수동으로 진행되면 본인의 코드가 다른 개발자의 코드에 영향을 주진 않는지 직접 확인해야만 알 수 있다는 문제가 있다. 그래서 9장에서는 깃허브에 푸시를 하면 자동으로 Test & Build & Deploy가 진행되는 환경을 만들어 본다. 9-1. CI / CD에 대한 소개 보통 하나의 프로젝트를 여러 개발자가 함께 개발을 하기 때문에 코

daydream

2시에 시작해서 10시에 트러블 슈팅 잡았습니다. 막상 해결하고 나니 단순한 문제였는데 오히려 많이 단순해서 해결하기까지 시간이 오래 걸린 트러블 슈팅이었습니다. 평소에 스택 트레이스 읽는 습관이 잡혀있어 다양한 시도가 가능했습니다. 앞으로도 계속 읽어야겠네요 배경 Travis CI Build Test Failed Build가 너무 느리고, 모든 테스트 케이스가 실패하는 상황 발생 local에서

wndudrla1011

[본 글은 프로젝트 과정을 기록할 목적으로 작성되었으며 아래 교재에 기반하여 작성됨] 🌱 CI & CD 소개 코드 버전 관리를 하는 VCS 시스템(Git, SVN 등) 에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 CI(Continuous Integration - 지속적 통합)라고 하며, 이 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD(Continuous Deployment - 지속적인 배포)라고 한다. 일반적으로 CI만 구축되어 있지는 않고, CD도 함께 구축된 경우가 대부분이다. 여기서 주의할 점은 단순히 CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아니다.

channi

전에 배포 자동화를 구현했는데, 배포되는 동안 서비스가 중단되는 문제가 있었다. 이제 무중단 배포를 해보겠다. 무중단 배포 방식 AWS에서 블루 그린 무중단 배포 도커를 이용한 웹서비스 무중단 배포 나는 Nginx를 이용해 무중단 배포를 할 것이다. Nginx 웹 서버, 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등을 위한 웹 서버이자 오픈소스 소프트웨어 리버스 프록시 엔진엑스가 외부의 요청을 받아 백엔드 서버로 요청을 전달하는 행위 리버스 프록시 서버(엔진엑스)는 요청을 전달하고 실제 요청에 대한 처리는 뒷단의 웹 애플리케이션 서버들이 처리한다. 하나의 EC2 혹은 리눅스 서버에 엔진엑스 1대와 스프링 부트 Jar를 2대를 사용한다. 엔진엑스는 80(http), 443(https) 포트를 할당한다. 스프링 부트 1은 8081 포트 스프링 부트 2는 8082 포트 엔진엑스 무중단

channi

CI 코드 버전 관리를 하는 VCS 시스템(Git, SVN 등)에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정 CD 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정 개발자 각자가 원격 저장소로 푸시할 때마다 코드를 병합하고, 테스트 코드와 빌드를 수행하면서 자동으로 코드가 통합 또한 배포가 자동 CI의 규칙 모든 소스 코드가 현재 실행되고 누구든 현재의 소스에 접근할 수 있는 단일 지점 유지할 것 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것 1. Travis CI 연동하기 Travis CI : 깃허브에서 제공하는 무료 CI 서비스

kyungwoon

항해 76일차 EC2, S3 관련 비밀 키를 포함하는 application.properties 파일을 깃허브에 그대로 올릴 수 없는 문제가 있어 처음에는 외부에 빼두고 외부파일을 읽는 방법으로 했지만 서버가 털리면 모든 정보를 잃을수도 있다는 조언으로 급하게 암호화 하는 방법을 찾아보았다. 여러 방법이 있었는데 Travis에서 파일을 암호화를 하여 깃허브에 올리고 travis에서 사용할 때는 파일을 복호화 해서 사용하게 만들 수 있다. Mac이 아닌 Window환경해서 하면 안된다는 팀원들이 많았다. Window에서는 리눅스에서 별도 진행해야 한다고 한다. Travis 설치 > sudo gem install travis Travis 로그인 > travis login --pro --github-token [본인 계정 토큰] 암호화 인텔리제이 터미널에서 암호화 하고자하는 파일 위치로 이동 후 암호화를 진행 > travis encrypt-file applicati

kyungwoon

항해 75일차 Travis CI와 CodeDeploy로 CI/CD 구성을 하였다. 배포 자동화까지 되었으니 무중단 배포까지 진행했다. 긴 시간은 아니지만, 새로운 Jar가 실행되기 전까진 기존 Jar를 종료시켜 놓기 때문에 서비스가 종료된다. 서비스를 정지하지 않고 배포하는 것을 무중단 배포라고 한다. Nginx가 가지고 있는 여러 기능 중 리버스 프록시가 있다. 리버스 프록시란 Nginx가 외부의 요청을 받아 백엔드 서버로 요청을 전달하는 행위를 이야기 한다. 리버스 프록시 서버(엔진엑스)는 요청을 전달하고, 실제 요청에 대한 처리는 뒷단의 웹 애플리케이션들이 처리한다. 우리는 이 리버스 프록시를 통해 무중단 배포 환경을 구축해 볼 예정이며 Nginx를 이용한 무중단 배포를 하는 이유는 가장 저렴하고 쉽다. 구조 하나의 EC2 혹은 리눅스 서버에 엔진엑스 1대와 스프링 부트 Jar를 2대를 사용한다. Nginx는 80(http), 443(https) 포트를 할

kyungwoon

항해 74일차 Travis CI와 AWS S3, CodeDeploy 연동 앞에서 S3연동까지 되었다. AWS의 배포 시스템인 CodeDeploy를 이용하기 전에 배포 대상인 EC2가 CodeDeploy를 연동 받을 수 있게 설정해보자. EC2에 IAM 역할 추가 S3 버킷을 생성하면서 IAM에서 사용자 추가를 하였다. 이번에는 사용자 추가가 아닌 역할 추가를 해야한다. >IAM의 사용자와 역할의 차이 역할 AWS 서비스에서만 할당할 수 있는 권한 EC2, CodeDeploy, SQS 등 사용자 AWS 서비스 외에 사용할 수 있는 권한 로컬 PC, IDC 서버 등 이번에 만들 권한은 EC2에서 사용해야 하기 때문에 사용자가 아닌 역할을 설정해준다. IAM에서 [역할]탭에서 역할 만들기 클릭 AWS서비스 / EC2선택 ![](https://images.velog.io/images/kyungwoon/post/de555

kyungwoon

항해 73일차 Travis CI와 AWS S3 연동 배포하기전에 Travis CI를 통해 빌드된 결과물을 보관할 수 있는 공간이 필요하다. AWS S3에 저장한다. S3 버킷 생성 파일들을 저장하고 접근 권한을 관리, 검색 등을 지원하는 파일 서버의 역할을 한다. 팀 프로젝트에서 S3를 사용하고 있는데 기존에는 게시글 작성 시 첨부되는 파일을 저장하는 용도로 사용하고 있다. 버킷 생성은 https://velog.io/@kyungwoon/TIL-%ED%95%AD%ED%95%B499-Day-50 참고하면 된다.(1번,2번,4번 과정 참고) 단, 2번 과정에서 모든 퍼블릭 액세스 차단에 체크해준다. 현재 프로젝트야 이미 깃허브에 오픈소스로 풀려있으니 문제없지만, 실제 서비스에서 할 때는 Jar 파일이 퍼블릭일 경우 누구나 내려받을 수 있어 코드나 설정값, 주요 키값들이 다 탈취될 수 있다. 퍼블릭이 아니더라도 IAM 사용자로 발급받은 키를 사용하니 접근 가능하므로 모

kyungwoon

CI/CD관련하여 Travis로 구현해보려고 한다. Travis CI 설정 https://travis-ci.com/ 에서 깃허브 계정으로 로그인을 한 뒤, github 연동을 활성화 프로젝트 설정 Travis CI의 상세한 설정은 프로젝트에 존재하는 .travis.yml / YAML로 설정 >YAML이란? 쉽게 말해서 jSON에서 괄호를 제거 했다고 생각하면 된다. YAML 이념이 "기계에서 파싱하기 쉽게, 사람이 다루기 쉽

kyungwoon

항해 71일차 2022.03.21 배포 자동화 서버에 기능을 추가 하려면 개발자가 로컬 PC에서 개발을 하고 테스트까지 진행한 뒤에 문제가 없을 경우 사용자가 사용할 수 있도록 수정된 코드를 실서버에 반영해야 한다. 서버에 반영을 하는 것을 "배포"라고 하고 배포(Deploy) 하기 위한 과정을 "빌드"라고 한다. 서비스에 사용자가 늘어나면서 운영하는 서버 또한 늘어난단다면 수동배포의 한계가 있을것이다. 운영하는 서버가 10대라고 하면, 10대를 모두 접속해 직접 배포할 파일을 SFTP를 통해 전달하고 서버를 종료하고 배포파일을 풀고 서버를 다시 실행시키는 작업을 10대에 진행을 해야하고 10대에 서버를 수동으로 진행하는 과정에서 배포가 누락되는 경우도 발생한다고 한다. 이런한 문제를 해결하기 위해 배포 자동화를 한다면 해결된다. 배포 자동화와 관련해서 Jenkins, Travis CI, Github Actions에 대해 알아보고 있다. Jenkins가 설치형이고 메모리를

rmswjdtn

Travis-ci 이제 Travis-ci를 붙여서 아래와 같은 flow를 만들어가도록 하겠습니다. Travis Ci는 github저장소에 push가 될때마다 전체 코드를 가져와서 테스트를 진행합니다. 그리고 테스트가 통과하면 AWS로 배포를 하도록 합니다. 이때 테스트를 통과하지 못하면 에러로그가 뜨고 배포를 하지는 않습니다! > github 레포와 travis-ci연결 1

nefertiri

이 포스팅은 "스프링 부트와 AWS로 혼자 구현하는 웹 서비스" 책을 보고 정리한 내용입니다. 이번 포스팅에서는 깃허브에 코드가 푸시되면 자동으로 빌드 및 배포가 이루어지는 환경을 구축해보겠습니다. 이전 포스팅에서 구축한 EC2 서버, RDS, 깃허브를 이용합니다. CI/CD란? 코드가 업데이트되면 자동으로 테스트와 빌드를 수행하고 배포 파일을 만드는 것을 CI(Continuous Integration)이라고 한다. 배포파일을 자동으로 운영 서버에 배포하는 것을 CD(Continuous Deployment)이라고 한다. 깃허브, Travis CI, AWS S3, AWS CodeDeploy, AWS EC2등의 서비스를 사용하여 CI/CD를 구축한다. 깃허브는 코드를 저장하는 저장소 역할을 한다. Travis CI는 깃허브 프로젝트를 테스트와 빌드를 수행하여 배포 파일을 만들고 AWS S3에 저장한다. AWS S3는 파일 서버 역할을한다. AWS Co