복습
git 사용법
init
git init
- `git config --global user.email "test@example.com"
- `git config --global user.name "cocudeny"
현재 작업을 저장(commit)
git add [filename]
git commit -m "message"
버전관리
git log
git checkout [버전 ID]
git checkout -
원격 저장소에 저장
- git remote add origin [원격저장소 도메인주소]
- git push origin [branch name]
- 원격 저장소 브랜치에 현재까지 저장(commit)된 버전 저장
git lab
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash EXTERNAL_URL="http://192.168.0.185" yum install -y gitlab-ce
cat /etc/gitlab/initial_root_password
protection 설정
- 개인 계정 > 프로젝트 > settings > repository > Protected branches > expand > unprotected 클릭
Git & Jenkins와 CI/CS PipeLine
1. Git과 Github의 이해
가. CI/CD 파이프라인 이해
- CI/CD 파이프라인은 새 버전의 소프트웨어를 제공하기 위해 수행해야 할 일련의 단계.
- 지속적 통합 / 지속적 배포(CI/CD) 파이프라인은 DevOps 또는 사이트 신뢰성 엔지니어(SRE) 방식을 통해 더 효과적으로 소프트웨어를 제공하는데 초점을 맞춘 방법이다.
- 특히 통합 및 테스트 단계와 제공 및 배포 단계에서 모니터링 및 자동화를 도입하여 애플리케이션 개발 프로세스를 개선한다.
파이프라인 단계 (Pipeline Stage)
- 빌드(build): 애플리케이션을 컴파일 하는 단계
- 테스트(Test): 코드를 테스트하는 단계. 이 단계를 자동화하여 시간과 수고를 줄일 수 있다.
- 릴리스(Release): 애플리케이션을 리포지토리에 제공하는 단계
- 배포(Deploy): 코드를 프로덕션에 배포하는 단계
- 검증 및 컴플라이언스(Validation & compliance): 빌드 검증 단계는 해당 조직에 따라 결정된다. Clair와 같은 이미지 보안 스캔 툴을 사용하여 알려진 취약점(CVE)과 비교하는 방법으로 이미지의 품질을 보장할 수 있다.
Dev Ops
- 각 단계별에서 필요한 도구들이 서로 맞물려 돌아가서 tool chain이라고도 한다.
2. Jenkins 이해 및 활용
가. Jenkins 이해 및 설치
- Jenkins는 지속적 통합(Continuous integraion, CI)과 지속적 배포(Continuous delivery, CD)를 위한 대표적인 도구이다.
- 빌드, 테스트, 배포 프로세스를 자동화하여 소프트웨어품질과 개발 생산성을 높일 수 있다.
- 플러그인 설치가 필요하다.
편리한 설정
- 웹 기반의 콘솔로 다양한 인증 기반과 결합이 가능하며, 권한 관리 기능을 통해 한전한 빌드/배포 환경을 구축할 수 있다.
안정적인 빌드/배포 환경
- 소스 버전 관리 출과 연동하여 코드 변경을 감지
- 자동화 테스트를 포함한 빌드를 수행하여 소프트웨어 품질 향상
- 자동화 테스트에는 코딩 표준 준수 여부 체크, 유닛 테스트, 통합 테스트 등을 설정할 수 있고, 결과에대한 피드백을 받을 수 있다.
다양한 활용 및 손쉬운 확장
redHat에서의 CI/CD PipeLine
AWS에서의 CI/CD PipeLine
- 수동적인 경향이 있다면 Continuous Delivery
- 수동적인 경향이 포함되어있지 않다면 Continuous Deployment로 생각한다.
go에서의 CI/CD PipeLine
- 여기서는 CD 과정에서 또한번 TEST가 들어간다.
- Staging 과정에서 Delivery에 Manual(수동)적인 부분이 들어가는 것이 Delivery로 하고, 완전 Automatic한 것을 Deployment라고 정의하고 있다.
Jenkins실습
EC2
EC2 생성
- 이름: jenkins-server
- AMI: Amazon linux
- t2.micro
- 보안그룹 규칙을 위와같이 설정하고 새로 생성해준다.
- 인스턴스 생성
Route53 레코드 생성
- 다음과같이 jenkins로 레코드를 생성해준다.
Jenkins
Jenkins 설치
- sudo su -
- 설치할 것이 너무 많아서, root계정으로 들어간다.
- wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
- jenkins.repository를 설정한다.
- rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
- rpm명령어로 jenkins 키를 가져온다.
yum install -y fontconfig java-11-openjdk
- 젠킨스를 설치하기 위해 자바가 필요하다.
- 아래 amazon-linux-extras 에서 추가 설치가 필요하나는 문구가 나온다. 설치해준다.
sudo amazon-linux-extras install java-openjdk11 -y
yum install -y jenkins
systemctl enable --now jenkins
- 젠킨스 시작하고 시작에 등록하기, 평소와달리 시간이 조금 걸린다.
cat /var/lib/jenkins/secrets/initialAdminPassword
- 초기 패스워드가 나온다.
6b9c7e8b4503466abffbc13bdf8c245e
- 로그인 후 바로 패스워드를 수정해준다.
Jenkins 시작
- 방금 설정한 도메인과 : 8080 포트로 접속하고, 방금 비밀번호를 입력해준다.
- 설정은 나중에 해줄 것이다.
- 젠킨스를 시작해준다.
- Admin -> 설정에서 패스워드를 바꿔준다.
- 바꾸는김에 Timezone도 서울로 바꿔준다.
- 패스워드를 바꾸면 로그아웃 되는데, 초기 계정의 ID는
admin
으로 되어있다.
Jenkins 프로젝트 생성
General
- 프리스타일 프로젝트라 가장 기본적인 항목만 들어가있다.
Build
echo "Hello World!"
uptime
Jenkins build
- 현재 Project HelloWorldJob을 보고있고,
- 지금 빌드를 클릭해본다.
- 잘 빌드된 결과가 나왔다.
- 클릭해보면, 실행한 명령어와, 그 출력을 볼 수 있다.
Jenkins 플러그인
github 플러그인 설치
- 젠킨스 관리 -> 플러그인 관리
- 설치 가능에서 github를 검색하고 체크해준 후, Install without restart를 눌러준다.
- Guthub외의 다른 의존성파일들도 같이 설치된다.
github 설치 후 설정
hostname
- hostnamectl set-hostname jenkins-server
- 호스트네임을 바꿔준다.
jenkins 새로운 프로젝트 만들기
General
소스코드관리
- 라디오버튼에 Git으로 체크하고,
https://github.com/hali-linux/hello-world.git
을 넣어준다.
- 이후 Apply -> Save해준다.
실행해보기
- 지금 빌드 클릭
- 성공적으로 마무리됬다.
- 콘솔 Output을 보면
/var/lib/jenkins/workspace/PullCodeFromGitHub
위치로 코드가 pull되었다고 나온다.
- 여기에 우리가 생성했던 프로젝트별로 저장되어 있는것을 볼 수 있다.
Maven
- Building하는 도구.
- IDE(통합 개발 환경)에 들어가있는 build 도구같이 Jenkins에서도 빌드 도구를 사용하는데 Maven을 사용할 것이다.
- 환경 변수 잡는것이 까다롭다.
Maven 설치
- https://maven.apache.org/install.html
- 여기서 Download link를 가져온다.
apache-maven-3.8.6-bin.tar.gz
cd /opt
wget https://dlcdn.apache.org/maven/maven-3/3.8.6/binaries/apache-maven-3.8.6-bin.tar.gz
tar -xvzf apache-maven-3.8.6-bin.tar.gz
- tar 명령어에서 z옵션은 반드시 f옵션 앞에 있어야한다.
- 다운로드 파일과 압축해제한 폴더들이 같이 있다.
mv apache-maven-3.8.6 maven
cd maven
- 여기 초록색 mvn이 maven을 실행하는 실행파일이며, 명령어이다.
cd ~
JAVA 찾기
find / -name java-11*
/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.amzn2.0.3.x86_64
- 실행명령어가 여기 있다.
vi .bash_profile
M2_HOME=/opt/maven
M2=/opt/maven/bin
JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.amzn2.0.3.x86_64
PATH=$PATH:$HOME/bin:$JAVA_HOME:$M2_HOME:$M2
경로설정확인
echo $PATH
source .bash_profile
- .bash_profile을 소스로, 즉 리프레쉬 해준다.
echo $PATH
mvn -v
Jenkins에서 플러그인 설치
플러그인 설정
- 여기서 Install Automaticaly를 체크 해제해준다.
- JAVA_HOME은 아까 환경변수 설정했던 그 경로를 넣어준다.
- JAVA_HOME=
/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.amzn2.0.3.x86_64
Apply & Save
Maven Test
새 프로젝트 생성
- 이름: FirstMavenProject
- MAVEN project 템플릿이 새로 생겼다. 클릭해주고 프로젝트를 생성한다.
General
소스코드관리
- 방금 전 코드 그대로 써준다.
https://github.com/hali-linux/hello-world.git
build
- POM.xml파일이 미리 정의되어있다.
- 우리는 WAR파일을 만들게 될 것이다. 이걸로 웹애플리케이션리소스 파일로 작업을 하게 될텐데
clean install
설정으로 매번 생성하는 WAR파일을 지우고 다시 설치하는 방법을 사용해준다.
Apply & Save
지금 빌드
- 현재 빌드 중이다.
- 빌드중에도 OutPut을 볼 수 있다. 현재 설치 후 TEST중이다.
- 잘 완료되었다.
디렉토리 확인
- 젠킨스 워크스페이스를 확인해본다.
- webapp이 .war파일로 잘 생성되었다.
- 이후에 .war파일을 TOMCAT으로 넘기면 되는 것이다.
Tomcat
tomcat-server 생성
- 이름: tomcat-server
- AMI: Amazonlinux2
- 보안그룹: dev-SG
- 사용자 데이터
#!/bin/bash
timedatectl set-timezone Asia/Seoul
hostnamectl set-hostname tomcat-server
Tomcat 설치
sudo su -
amazon-linux-extras install -y java-openjdk11
cd /opt
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.65/bin/apache-tomcat-9.0.65.tar.gz
- tomcat 최신버전은 10이지만, 안정화된 9버전의 최신버전을 사용한다.
- tomcat 압축파일 다운로드
tar -xvzf apache-tomcat-9.0.65.tar.gz
mv apache-tomcat-9.0.65 tomcat
cd tomcat/bin/
./startup.sh
- 톰캣 기동
- 톰캣페이지가 잘 나온다.
- Manager App을 눌러 진입이 가능해야한다.
- 그러나 아직 에러가 나온다.
cd /opt/tomcat
- tomcat파일로 이동한다.
- `find / -name context.xml
- find 명령어로 context.xml파일을 찾았다.
- context파일에는 권한 관련 내용이 들어가있다.
- 먼저 host-manager의 컨텍스트를 수정한다.
vi /opt/tomcat/webapps/host-manager/META-INF/context.xml
- 위 이미지부분 Valve 부분을 주석처리해준다.
vi /opt/tomcat/webapps/manager/META-INF/context.xml
- 여기도 똑같이 주석처리 해준다.
- 다시 ManageApp으로 들어가면 위와 같은 화면이 나오게된다.
- 위 계정 정보는
cd /opt/tomcat/conf/tomcat-users.xsd
에서 설정할 수 있다.
- vi tomcat-users.xml
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="admin" password="kosa0401" roles="manager-gui, manager-script, manager-jmx, manager-status"/>
<user username="deployer" password="kosa0401" roles="manager-script"/>
<user username="tomcat" password="kosa0401" roles="manager-gui"/>
</tomcat-users>
- jenkins에서 Tomcat에 로그인 할 수 있도록 설정해주는 것이다.
- 위에서 설정한 username과 password로 젠킨스에서 credential을 생성해 줄 것이다.
tomcat start down 명령어 성생
ln -s /opt/tomcat/bin/startup.sh /usr/local/bin/tomcatup
- tomcat을 시작하는 startup 명령어를 tomcatup으로 bin에 등록한다.
ln -s /opt/tomcat/bin/shutdown.sh /usr/local/bin/tomcatdown
Tomcat과 Jenkins 연결
플러그인 설치
- deploy to container를 찾아 설치해준다.
credential설정
- 아까
vi tomcat-users.xml
에서 정의한 username과 password를 사용한다.
새로운 프로젝트
- 이름: BuildAndDeployJob
- MavenProject
상세 설정
General
소스코드 관리
Build
- WAR 파일이 계속 빌드할 떄마다 생성될텐데, 매 빌드마다 기존 WAR파일을 clean하고 다시 install 한다.
빌드 후 조치
**/*.war
- 무슨 경로이던지, war 파일이 어떤 이름이던지 인지하겠다.
- Container의 버전은 Tomcat 9.x Remote (구버전)을 사용한다.
- Credential정보로 Tomcat 로그인계정정보를 넣어준다.
- Tomcat URL은 TOMCAT 도메인주소를 넣어준다.
메가존인터뷰
클라우드 환경의 기술 트렌드
IT 트렌드 변천사
- Legacy System -> Unix(가격이 비쌈) 1억 -> Linux(2.4, Centos5버전부터) 1/3부피 300만원 -> 가상화 솔루션 (physical -> Virtual) -> 클라우드 컴퓨팅 (Pysical -> Cloud)
- 아직 핵심을 Cloud로 넘긴 사례는 아직 없다.
- Native Cloud
- 플랫폼을 이식하는 것 뿐만 아니라, 서비스를 어떻게 AutoScaling 할건지 고민하는 설계부터 Native Cloud이다.
- DevOps
- 하나의 직군? 문화? 개발자와 운영자 사이있는 모든 직군?
- DevSecOps : DevOps + Security?
- CI/CD파이프가 서비스별로, 환경별로 나와야하낟.
- GitOps : DevOps에 형상관리를 강화하기위해 Git사용
- MLOps: 머신러닝 데이터 수집, 전처리, 모델링 계획, ... 배포까지
- DDD: Domain Driven Design, Micro Service, 어플리케이션 설계시 어디까지 도메인? 어떻게 서킷브레이크?
- 그 외, Migration IoT등 모든 기업들이 고민하고 있다.
업계의 최근 소식
- EdgeComputing
- 초 저지연, 초연결, VR에서느느 Extended Reality
- 멀티 클라우드, 분산 클라우드
- 실제 1위인 AWS에서는 언급하지 않는다.
- 그외 다른 CSP에서 좋은 서비스에서골라 사용하는 기법
- 그런데 보안, 관리 등 복잡한 문제가 있다.
- 비용 절약에 대한 도전.
- Space one 과 같은 솔루션
- 인공지능 및 기계학습
- AutoML : 파라미터를 알아서 조정해서 최적의 모델을 찾는것.
- Smart Contact Centor
- Chatbot -> Callbot: 자연어 처리. Speach to Text -> 의도 분석 -> Text to Speach
- 초 자동화
- IT 프로세스의 자동화
- Low code, No code : 명세서만 넣으면 코드를 알아서 생성해줌
- Data LakeHouse
- 기계학습, 인공지능에 필요한 데이터
- Data Warehous : 정형화된 데이터
- Data Lake: 비정형화된 데이터도 가능, AWS s3, Wasabi, 대용량데이터처리, 빠른처리
- Data Lakehouse: Lake를 가시화, UI로 검색화, databrick 솔루션.
- 자연어 처리를 통한 Business intelligence
- AWS quick site: 보고할 대시보드를 데이터를 수집하고, 자연어처리로 만들어줌.
Solutions Architect가 되어야하는 이유
- 고객의 요구사항을 정확하게 이행 및 구현
- 고객 서비스를 클라우드 기반으로 개발 및 운영할 수 있도록 돕는 협력자.
역할
- 아키텍처 설계
- 인프라 , 플랫폼 구축
- 마이그레이션
- 문서화
- 교육
- 커뮤니케이션
일하는 방법
자격조건
- 새로운것에 도전 함께성장
- 고객에게 가치 전달
- 능동적 업무, IT공부 재미
- AWS 인프라 구축 경험
- Cloud 서비스 이해, 기초 대한 지식
SA커리어
- General -> Specialty SA, DebOps
SpaceOne
Hyper Solution
ISV
인재상
- 기술지향
- 고객 중심
- 신뢰와 소통
- 실행을 통한 성장
CTC
신규입사자 여정 소개
주 업무
주니어 SA
- 3개월 간 교육
- 세션 참가
- 쉐도우 미팅
- 온보딩 과제 수행 및 발표
- 6개월
- 인프라 구축, 프로젝트 수행
- AWS 101 고객사 교육
- 9개월
- AWS 데이터 파이프라인 구축 프로젝트 수행
- AWS 데이터 서비스 고객사 교육
- 온보디 학습 및 수료, 고객사 교육
- 팀 워크샵
- 버디 식사
- Game Day : 아키텍팅 대회
CTC
QnA
- 처음 입사 후, 교육, 3번의 발표가 모두 패스되어야한다.
- 클라우드 마이그레이션 후, 온프레미스로 돌아간 경우 (비용?, 규제?)
- 고객사의 대외 서비스가 잘 돌아가는것이 목표기 떄문에 무조건 클라우드 마이그레이션하지는 않는다.
- 마이그레이션할떄 고객의 개발부서, 재무부서, 대표 등 모든 의지가 한마음이어야 된다.
면접 프로세스
- 서류전형
- 1차면접 비대면 30분~1시간 (학부생, 교육에서 했던것, 스트레스 관리 능력, 할 의지)
- 1주일 이내 합불
- 2차인터뷰, 인사처우 회의
- 3개월 온보딩
- 신입 야근 가장많... 주륵
채용확정교육?
- 채용 상한선. CTC 등 다양한 센터가 존재. 특정 산업군을 위한 센터에서 뽑을 수 있다.
프로젝트
- 왜 이 아키텍트를 사용했나?
- 어떻게 보안? 어떻게 merge? 여러 개발자가 협업할떄 어떻게? 가용성은?
서류심사시 중점적
프로젝트
- 상황 가정
- 언어 가정
- 어떤 서비스를 배포
- DevSecOps , 언어 가이드라인(메모리누수, CPU 모니터링), 어떻게 빠르게 배포, 옵션, 관리, 배포 승인절차.
- 인프라레벨, 개발자 시각, 최적화, 보안담당자입장에서, 운영자입장에서 어떻게 트래픽을 유지하며 배포?
쿠버네티스
- PersistentVolume
- 노드, 트랙젝션이 점점많아지면 버틸 수 있나?
- 안정성, 6개월마다 보안패치가 나왔다면 패치하는것도 어렵다.
- node버전과 kubelet버전도 맞춰야한다.
- 장애났을 때, 고객의 신뢰를 다 잃어버리게 된다.
- 그린카 48시간 장애있었다.
장단점
- 체계가 명학하지 않다.
- 고객 대상 스타트업 -> 핀테크 -> 블록체인
- 다양한 고객사의 다양한 프로젝트, 유형과 업종들이 모두 다르다.
- 회사내 키 유출사고, 내부에서 더 좋은 방법으로 찾아 계속 다듬어나간다. 주도적으로 변화