220727

HyeonKi Jo·2022년 7월 27일
0
post-thumbnail

복습

git 사용법

init

  • git init
    • 현재 디렉토리를 git으로 사용
  • `git config --global user.email "test@example.com"
  • `git config --global user.name "cocudeny"
    • user정보 config

현재 작업을 저장(commit)

  • git add [filename]
    • 현재버전 git에 add
  • git commit -m "message"
    • git에 현재 버전을 commit

버전관리

  • 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
    • git lab 설치
  • 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 새로운 프로젝트 만들기

  • 이름: PullCodeFromGitHub

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
# User specific environment and startup programs

PATH=$PATH:$HOME/bin:$JAVA_HOME:$M2_HOME:$M2

경로설정확인

  • echo $PATH
    • 아직 java 환경변수가 설정되지 않았다.
  • source .bash_profile
    • .bash_profile을 소스로, 즉 리프레쉬 해준다.
  • echo $PATH
    • 이번에는 java의 경로가 잘 나온다.
  • mvn -v
    • maven의 버전이 제대로 잘 나온다.

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

  • 생성하며, Route53까지 설정해준다.

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
    • 이름이 길어 tomcat으로 줄여준다.
  • cd tomcat/bin/
    • 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"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<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">
<!--
  By default, no user is included in the "manager-gui" role required
  to operate the "/manager/html" web application.  If you wish to use this app,
  you must define such a user - the username and password are arbitrary.

  Built-in Tomcat manager roles:
    - manager-gui    - allows access to the HTML GUI and the status pages
    - manager-script - allows access to the HTTP API and the status pages
    - manager-jmx    - allows access to the JMX proxy and the status pages
    - manager-status - allows access to the status pages only

  The users below are wrapped in a comment and are therefore ignored. If you
  wish to configure one or more of these users for use with the manager web
  application, do not forget to remove the <!.. ..> that surrounds them. You
  will also need to set the passwords to something appropriate.
-->
<!--
  <user username="admin" password="<must-be-changed>" roles="manager-gui"/>
  <user username="robot" password="<must-be-changed>" roles="manager-script"/>
-->
<!--
  The sample user and role entries below are intended for use with the
  examples web application. They are wrapped in a comment and thus are ignored
  when reading this file. If you wish to configure these users for use with the
  examples web application, do not forget to remove the <!.. ..> that surrounds
  them. You will also need to set the passwords to something appropriate.
-->
<!--
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="<must-be-changed>" roles="tomcat"/>
  <user username="both" password="<must-be-changed>" roles="tomcat,role1"/>
  <user username="role1" password="<must-be-changed>" roles="role1"/>
-->
  <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
    • tomcatdown도 마찬가지로 등록해준다.

Tomcat과 Jenkins 연결

플러그인 설치

  • deploy to container를 찾아 설치해준다.

credential설정




  • 아까 vi tomcat-users.xml에서 정의한 username과 password를 사용한다.

새로운 프로젝트

  • 이름: BuildAndDeployJob
  • MavenProject

상세 설정

General

  • 프로젝트에 대한 설명 넣기

소스코드 관리

  • git 코드를 여기서 가져온다.

Build

  • WAR 파일이 계속 빌드할 떄마다 생성될텐데, 매 빌드마다 기존 WAR파일을 clean하고 다시 install 한다.

빌드 후 조치



  • **/*.war
    • 무슨 경로이던지, war 파일이 어떤 이름이던지 인지하겠다.
  • Container의 버전은 Tomcat 9.x Remote (구버전)을 사용한다.
  • Credential정보로 Tomcat 로그인계정정보를 넣어준다.
  • Tomcat URL은 TOMCAT 도메인주소를 넣어준다.

메가존인터뷰

클라우드 환경의 기술 트렌드

  • 현직 트렌드, 올해 트렌드, 그에대한 QnA

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

  • 스킬 Up

QnA

  • 처음 입사 후, 교육, 3번의 발표가 모두 패스되어야한다.
  • 클라우드 마이그레이션 후, 온프레미스로 돌아간 경우 (비용?, 규제?)
    • 고객사의 대외 서비스가 잘 돌아가는것이 목표기 떄문에 무조건 클라우드 마이그레이션하지는 않는다.
    • 마이그레이션할떄 고객의 개발부서, 재무부서, 대표 등 모든 의지가 한마음이어야 된다.

면접 프로세스

  • 서류전형
  • 1차면접 비대면 30분~1시간 (학부생, 교육에서 했던것, 스트레스 관리 능력, 할 의지)
  • 1주일 이내 합불
  • 2차인터뷰, 인사처우 회의
  • 3개월 온보딩
  • 신입 야근 가장많... 주륵

채용확정교육?

  • 채용 상한선. CTC 등 다양한 센터가 존재. 특정 산업군을 위한 센터에서 뽑을 수 있다.

프로젝트

  • 왜 이 아키텍트를 사용했나?
  • 어떻게 보안? 어떻게 merge? 여러 개발자가 협업할떄 어떻게? 가용성은?

서류심사시 중점적

  • 프로젝트도 많이 본다.
  • 얼마나 노력?

프로젝트

  • 상황 가정
  • 언어 가정
  • 어떤 서비스를 배포
  • DevSecOps , 언어 가이드라인(메모리누수, CPU 모니터링), 어떻게 빠르게 배포, 옵션, 관리, 배포 승인절차.
  • 인프라레벨, 개발자 시각, 최적화, 보안담당자입장에서, 운영자입장에서 어떻게 트래픽을 유지하며 배포?

쿠버네티스

  • PersistentVolume
  • 노드, 트랙젝션이 점점많아지면 버틸 수 있나?
  • 안정성, 6개월마다 보안패치가 나왔다면 패치하는것도 어렵다.
    • node버전과 kubelet버전도 맞춰야한다.
    • 장애났을 때, 고객의 신뢰를 다 잃어버리게 된다.
    • 그린카 48시간 장애있었다.

장단점

  • 체계가 명학하지 않다.
    • 고객 대상 스타트업 -> 핀테크 -> 블록체인
    • 다양한 고객사의 다양한 프로젝트, 유형과 업종들이 모두 다르다.
    • 회사내 키 유출사고, 내부에서 더 좋은 방법으로 찾아 계속 다듬어나간다. 주도적으로 변화
profile
Talking Potato

0개의 댓글