Coding (164)

Coding/Today I Learned
2022.01.06(Thu.) <다시 처음으로 돌아가 알아보는 HTML 태그>
2022
0107
  • 2022.01.06(Thu.) <다시 처음으로 돌아가 알아보는 HTML 태그>
    2022.01.07
    • Coding/Project
    Project : Meal To Meal 회고
    2021
    1225
  • Project : Meal To Meal 회고
    2021.12.25
    • Coding/Project
    Project : Maplody 회고
    2021
    1224
  • Project : Maplody 회고
    2021.12.24
    • Coding/Today I Learned
    2021.09.16(Thu.) <AWS 배포의 큰 그림>
    2021
    0916
  • 2021.09.16(Thu.) <AWS 배포의 큰 그림>
    2021.09.16
    • 01
    07
    Coding/Today I Learned

    2022.01.06(Thu.) <다시 처음으로 돌아가 알아보는 HTML 태그>

    무시하지 마십시오...모두가 무시하지만 똑바로 하는 사람은 잘 없습니다. 그래도 html 프로그래머는 좀..ㅎㅎ;;

    1. 문제의 발단

    2개의 프로젝트를 끝낸 지금, 가장 필요한 것은?? 당근 복습이다. 했던 거 또 하고 또 하고 또 한다.

    프로젝트를 진행할수록 이미 다 배웠지만 빈틈이 더 느껴지기 시작했고, 그렇기 때문에 다시 복습하고 정리하기 위해 돌아왔다.

     처음 시작은 html 태그의 심오함이다. 생각보다 태그들을 잘 나눠 사용하지 않았던 기억이 있다. 대부분은 div로 처리하고 css로 조절해 버렸기 때문이다. 이는 검색과 가독성, 유지보수에 몹시 안 좋다. 그래서 습관처럼 사용할 수 있도록 확실히 태그에 대해 알고 가면 좋을 것 같다.

    2. Semantic Tags

    • '의미'가 있는 태그를 말한다.
    • 제목(h 태그), a(링크), button 등의 다양한 종류의 의미가 있는 태그들을 뜻한다.
    • 이들은 각자의 모양이 있고 따로 css를 설정하지 않아도 그 모양대로 처음부터 나타난다.

    3. Tag의 종류

    • <html /> : html 문서의 최상단을 나타내는 태그. 모든 태그들은 이 태그의 자손들이어야 한다는 규칙이 있다.
    • <header /> : 브랜드 로고, 사용자에게 나타나야 할 메뉴
    • <nav /> : 메뉴 안의 요소들
    • <footer /> : 가장 하단의 링크나 재작자의 시그니처들
    • <main /> : 중요 콘텐츠
    • <aside /> : 콘텐츠와 관련없는 광고 같은 것들
    • <article /> : 콘텐츠와 독립적으로 구성될 수 있는 요소들
    • <section /> : 문서와 문서를 분리하여 주제가 다른 문서를 쓰는 경우 사용할 수 있음
      • article VS section : 가장 큰 차이로는 article은 혼자만 딱 때와서 내용을 보아도 이해가 되어야 한다. 독립적인 내용이기 때문에 요소 안에 모든 것 내용들이 다 있어야 하기 때문이다. 그에 비해 section은 같은 카테고리 안의 주제가 다른 경우, 마치 우리가 들여 쓰기를 하듯이 사용할 수 있다. 그렇기 때문에 section이 여러 개인 상황에 그 section안에 독립적으로 article이 존제하는 형태가 자주 보인다. 
    • <div /> : 그저 의미 없이 요소를 묶기 위해 사용하는 태그
    • <span /> 그저 의미 없이 요소를 묶기 위해 사용하는 태그
      • <div /> VS <span /> : div는 brock 속성으로 한 줄의 모든 부분을 차지한다. span은 inlien 속성으로 콘텐츠의 사이즈만큼만을 차지한다.
    • <address /> : 주소, 연락에 관련한 내용
    • <h1~6 /> : 제목. 번호가 커질 수 록 사이즈는 줄어든다.
    • <em /> : 강조를 포함한 기울임체(이탤릭체)
    • <i /> : 강조 없이 그저 시각적으로만 기울임체(이탤릭체)
      • 폰트 어썸 : 주로 <i />를 이용하여 표현한다. 역시 태그의 의미 그대로 강조 없이 일반적인 내용들과 차이를 표현하기 위해 <i /> 태그를 사용하며, <span />를 사용해도 되지만 검색 툴들이 정확한 의미를 이해하고 사용할 때 더 유리하므로 <i />를 사용한다고 한다.
    • <strong /> : 강조를 포함한 굵은 체(볼드체)
    • <b /> : 강조 없이 그저 시각적으로만 굵은 체(볼드체)
    • <ol /> : 순서가 필요한 목록을 나타내는 태그
    • <ul /> : 순서가 없는 목록을 나타내는 태그
    • <li /> : list item
    • <dl /> : 어떤 단어의 설명이 필요할 때 설명할 대상의 제목과 내용을 묶는 태그
    • <dt /> : 설명할 대상의 타이틀
    • <dd /> : 설명할 대상의 내용
    • <img /> : 콘텐츠에 중요한 내용이 될 이미지
      • <img /> VS CSS background-image 속성 : 콘텐츠의 내용이 아니며 배경이 강조될 필요가 없고, 이미지가 없다고 해서 콘텐츠에 내용에 영향을 미치지 않는다면 태그로 만들지 말고 css 속성으로 넣는 것이 맞다. 그래야 검색 툴이 헷갈리지 않는다.
    • <button /> : 유저의 행동이 발생할 경우 
    • <a /> : 페이지를 이동하는 등의 링크
    • <table /> : 중요한 데이터가 표에 들어가서 의미가 있을 경우
      • 의미가 없는 데이터의 경우(보기 편하게 하기 위해서 사용할 경우)는 css flex-box로 조절하는 것이 역시나 검색 툴이 안 헷갈린다.
    • <br /> : 텍스트의 줄 바꿈
    • <cite /> : 출처를 나타내는 태그. 제목을 반드시 포함해야 한다.
    • <ruby /> : 주석. 혹은 동아시아 문자의 발음을 나타낼 때 쓴다고는 하는데... 주석으로 더 쓸 것 같다.
    • <samp /> : 출력의 예시나 인용문을 나타내는 태그
    • <s /> : 취소선
    • <small /> : 덧붙이는 글이나 저작권 및 법률에 관한 표기를 하는 태그
    • <sub /> : 글자 아래에 작게 숫자나 글자를 쓰고 싶을 때 쓰는 태그 Ex) 화학기호나 수학 기호를 표시할 때, 산소(O2)의 경우 숫자 2를 작게 쓰는 것이 맞다.
    • <sup /> : <sub />의 반대로 위로 쓰는 경우 사용한다. 제곱을 표현할 수 있다.
    • <time /> : 시간을 표현할 때 사용하는 태그
    • <audio /> : 소리
    • <track /> : <audio />나 <video />의 자식으로 사용해서 시간별로 저장할 위치에 사용한다.
    • <canvas /> : 캔버스 스크립팅 API나 WebGL API와 함께 사용하여 그림이나 애니메이션을 그릴 때 사용한다.
    • <noscript /> : 페이지 스크립트 유형을 지원하지 않거나 스크립트를 비활성화한 경우 보여줄 것을 넣는 태그이다.
    • <script /> : 자바스크립트 코드를 넣을 곳
    이때까지 사용하지 않은 태그들이 엄청 많다는 것을 다시 느꼈다. 역시 기본이 중요하다는 것을 다시 확실히 깨달았고, 천천히 부족한 디테일을 채워나가자.
    저작자표시

    'Coding > Today I Learned' 카테고리의 다른 글

    2022.01.11(Tue.) <일단 쓰면서 배우는 Figma>  (0) 2022.01.11
    2022.01.08(Sat.) <TypeScript의 기초>  (0) 2022.01.08
    2021.09.16(Thu.) <AWS 배포의 큰 그림>  (0) 2021.09.16
    2021.09.14(Tue.) <Git을 이용한 버전관리>  (0) 2021.09.14
    2021.09.13(Mon.) <조금 더 알아보는 네트워크>  (0) 2021.09.13
    COMMENT
     
    12
    25
    Coding/Project

    Project : Meal To Meal 회고

    따뜻한 한 끼를 주변의 이웃들과 나누는 작은 기적! 주는사람, 받는사람, 제공하는 사람도 행복한 기부 플렛폼 Meal To Meal 입니다!

     

    Meal To Meal

     

    mealtomeal.shop

    역시나 욕심을 이기지 못하고 영혼을 깎아 가며 만들었던 프로젝트였다.

    분명 우리는 다짐했다. 첫번째 프로젝트 이후 체력이 하나도 남지 않은 팀원들은 '아... 적당히 하자', '우리 할 수 있는 만큼만 하자!'라고 이야기하고 있었고, 아이디어를 모으기 시작했다. 하지만 '기부'와 '리뷰' 심지어 라임까지 비슷한 이 두 단어가 합쳐지니 너무 매력적으로 보였고 우리는 어차피 고통은 미래의 내가 책임진다...!라는 이야기를 하며 기획에 들어갔다. 물론 결과는 대성공...

     

    이번 프로젝트에서 잘 한 점은?

    - 아이디어가 참신하다. 처음부터 우리는 두가지 중에 선택하기로 하였다. 이미 나와있던 서비스이지만, 더 뛰어나고 쓰기 편한 서비스를 우리 형식대로 만들면 좋겠다는 의견과 아예 세상에 없는 것을 만들어 세상에 본때를 보여주자!라는 의견이었다. 결국 후자가 이겼고, '기부 플랫폼'이라는 생소한 주제로 관심을 돌렸다. 그러나 일반적인 기부 플랫폼이 아니라 서로 기부한 사람과 기부받은 사람이 연결되어 자신의 기부가 어떻게 쓰이는지 알 수 있다면 좋겠다고 생각했고, 기부를 받는 사람과 기부를 주는 사람만 뿌듯한 것이 아니라, 그 중간에 기부를 제공하는 사람도 행복할 수 있는 시스템이 좋겠다고 생각했다. 그래서 Meal To Meal의 경우 음식을 기부받은 후 필수적으로 리뷰를 남기도록 하여 가게 사장님 또한 음식이 맛있어서 기부하고 싶은 음식점, 진정성 있는 리뷰를 모을 수 있으므로 맛집의 증거가 될 수 있는 것이다.

    - 유저의 응답에 의한 사소한 디테일을 잘 챙겼다. 가게 사장님이 자신의 가게에서 먹기 버튼을 눌러 기부받은 음식을 주지 않고 소모시켜 버리면 어쩔까? 아이디를 하루에 1000개 씩 가입해서 돈을 안 내고 음식을 계속 먹는 사람이 있으면 어쩔까? 가게 사장님은 어떻게 주문한 사람을 확인해야 할까? 등등 사소하게나마 플랫폼을 악용할 수 있는 부분을 최대한 막으려고 노력했다. 그러다 보니 기능들이 점점 늘어나기도 했지만 디테일을 유저 입장에서 생각할 수 있었던 점이 좋았다.

     

    이번 프로젝트에서 아쉬운 점은?

    - 역시나 끝없는 욕심으로 인한 탈진이 아쉽다. 하지만 이번 기회로 깨닳은것도 있다. 욕심을 막을 수 없다면, 더 자세히 SR을 해서 최대한 시간을 벌고 능률적으로 개발하는 것이다.

    - 랭킹 시스템을 만들지 못 했다. 기부 플랫폼이니 누가 가장 많은 기부를 하였는지 보여줄 수 있다면 경쟁심을 유발해 더 많은 기부를 유도할 수 있을 것이라고 생각하였다. 하지만 시간의 부족으로 만들지 못했다. 추후에 진행할 수 있을 것이다.

    - seed 파일로 찍혀있는 가게의 마커들이 주소가 올바르지 않다. seed 파일을 만들었을때, 좌표는 서울 안에서 렌덤으로 주고 주소는 전부 통일시켰다. 그래서 seed를 없애고 다시 만들면 마커의 위치가 바뀐다. 그렇게 테스트를 위한 seed를 만들다 보니 주소까지는 정확히 받아올 필요가 없다고 생각하였다. 하지만 이왕이면 그것도 정확히 받아 올 수 있다면 좋겠다고 생각하였다. 물론, 새롭게 가게를 등록하여 새로운 마커를 만들 때는 정확히 주소를 검색하여 좌표까지 검색하기 때문에 정확한 주소와 위치에 마커가 찍히도록 되어있다.

    저작자표시

    'Coding > Project' 카테고리의 다른 글

    Project : Maplody 회고  (0) 2021.12.24
    COMMENT
     
    12
    24
    Coding/Project

    Project : Maplody 회고

     

    Maplody

     

    maplody.site

    첫 번째 프로젝트인 'Maplody'는 항상 기대를 넘어서는 프로젝트였다.

     몇 번의 side 프로젝트들을 스터디에서 진행했고, 그때 함께 했던 팀원들과 그대로 다시 팀을 꾸려 작업을 시작하게 되었다. 그랬던 덕분에 커뮤니케이션 문제는 전혀 없었다. 서로 하고 싶은 말을 편하게 할 수 있었고 부족한 점과 잘한 점, 그리고 서로의 도움이 필요할 때도 눈치 보지 않고 언제나 서로가 서로를 도우며 작업할 수 있었다. 그래서 정말 즐겁게 작업할 수 있었고 결국, 기획단계에서 계획했던 것보다 더 괜찮은 결과물을 만들 수 있었다.

     

    이번 프로젝트에서 잘 한 점은?

    - 구현하고자 하는 모든 기능들을 구현하였다. 처음에는 Spotify API를 통해 음악을 재생하고 검색시스템을 넣으려고 했지만, 가장 중요한 것을 잊고 있었다. 바로, 팀원들 중 아무도 Spotify를 사용하는 사람이 없었다는 것이다...! 국내 서비스인 Melon은 API 시스템을 더 이상 제공하지 않는다고 하였다. 하지만 이전부터 생각한 대체안이었던 YouTube API를 이용해 심지어 무료로 양질의 음악을 찾아 재생시키는 기능을 넣을 수 있었다. 이처럼 '안 되면 어쩌지'라는 작은 의심에 하나하나 대책을 세워놓았기 때문에 문제가 생겼을 때 빠르게 정상적인 궤도에 다시 올라올 수 있었다.

    - Wireframe과 Flow Chart를 사전에 확실하게 구성하였다. 덕분에 프로젝트 개발에만 온전히 집중할 수 있었다. 물론 Wireframe에 적혀 있는 그대로 만들지는 않았다. 점점 컴포넌트들이 완성되는 과정에서 더 나은 부분이 있다면 계속 팀원들과 상의를 통해 개선해 나갔기 때문이다. 덕분에 더 새련된 디자인을 얻을 수 있었다. Flow Chart는 이전에 했던 side 프로젝트의 교훈이었다. 그때는 백엔드 작업을 했었는데 주도적으로 어떻게 유저가 사용할까?라는 것을 따라가면서 기능을 확실히 잡고 진행했던 것이 도움이 되었기 때문이다.

     

    이번 프로젝트에서 아쉬운 점은?

    - 역량과 시간을 고려하지 않은 계획의 설정이 아쉽다. 처음 기획단계에서 각오도 단단히 했고, 분명 작업량이 많다는 것도 알고 있었지만 그래도 욕심이 너무 많았던 프로젝트였다. 덕분에 계획했던 Advanced List를 전부 해치우지 못해서 아쉽다! 이는 점점 채워나가도 괜찮을 것 같다.

    - 배포과정에서 UX를 편하게 만드는 기능 몇 가지가 작동하지 않았다. 분명 로컬에서 작업했을 때에는 마커를 생성하거나 삭제 시 바로 화면이 redirect 되면서 변경사항을 바로 보여줬었는데, 그 부분을 구현하고 배포를 진행하고 나니 작동하지 않았다. 이 부분도 고쳐봐야 할 부분이다.

     

     

     

    저작자표시

    'Coding > Project' 카테고리의 다른 글

    Project : Meal To Meal 회고  (0) 2021.12.25
    COMMENT
     
    09
    16
    Coding/Today I Learned

    2021.09.16(Thu.) <AWS 배포의 큰 그림>

    안그래도 쫄아서 빨리 껐읍니다.

    1. 문제의 발단

    • 만드는 것만큼 배포도 중요하다.
    • 내 불쌍한 컴퓨터로 서버를 돌리는 것은 너무하다.
    • 그래서 우리는 돈을 주고 안 보이는 서버를 사서 사용할 수 있다!

    2. AWS

    • Amazon Web Services를 줄인 것이다.
    • 개인의 온 프레미스 환경(직접 컴퓨터에 서버를 열어 관리함)의 서버는 많은 응답을 처리하기 위해 수많은 비용과 인력이 엄청나게 들어간다.
    • 그것을 대신 클라우드 서비스를 이용해 대신 가상의 컴퓨터로 대신 서버를 관리해주는 서비스이다.

    3. 클라우드 서비스의 종류

    1. SaaS(Software as a Service): 네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스, 어플리케이션을 제공함
    2. PaaS(Platform as a Service): 네트워크, 하드웨어, 운영체제, 플렛폼/데이터 베이스를 제공함
    3. IaaS(Infrastructure as a Service): 네트워크, 하드웨어를 제공함

    4. AWS가 하는 서비스

     EC2(Elastic Compute Cloud)

    • 가상의 컴퓨터를 제공한다.
    • 나처럼 우분투와 씨름하지 않고 클릭 몇 번으로 OS가 완벽하게 돌아가는 컴퓨터를 사용할 수 있게 된다.

     RDS(Relational Database Service)

    • 데이터베이스를 내가 관리할 필요 없이 대신 만들고 관리해준다.
    • 규모를 확장시키기도 편하고, 내구성도 완벽하며, 데이터도 안전하다. 백업도 쉽게 가능하다.

    S3(Simple Storage Service)

    • 우리가 자주 사용하는 네이버 클라우드, OneDrive같은 클라우드 서비스라고 생각하면 편하다.
    • 역시나 데이터를 무한하게 저장할 수 있으며, 매우 안전하게 보관된다.
    • AWS는 이러한 서비스를 제공하기 위해서 전 세계에 각국, 각 도시에 진짜 서버를 가지고 있다. 그 장소를 '리전(Region)'이라고 하고, 그렇기 때문에 이러한 서비스를 전 세계인에게 제공할 수 있게 된다.

    5. 그래서 어떻게 배포할까요?

    1. EC2를 이용해 인스턴스를 생성한다.
      • '프리티어 사용가능' 이라고 적힌 인스턴스는 돈이 들지 않는다. 연습용으로 사용하자.
      • 인스턴스 유형(CPU나 램 등)도 프리티어가 있는 것을 선택하자.
      • 원격으로 인스턴스에 접속해서 조작할 것이기 때문에 'Key'를 생성하게 된다. 'SSH 프로토콜'로 '.pem' 확장자인 파일을 이용해 조작 권한을 얻을 수 있다.
    2. EC2로 생성한 인스턴스를 로컬에 연결한다.
      • 아까 만든 인스턴스를 클릭하고 우측 상단에 '연결'을 눌러 준비한다.
      • SSH접속을 하기 위해 pem키의 권한을 수정한다. 'chmod 400' 명령어(복사할 수 있게 되어 있다)로 소유자 만이 읽기 권한 만을 소유자에게 부여한다.
      • ssh 명령어(ssh -i"키 이름"사용자 이름(OS 이름이 될 것이다)@가상 PC 주소)로 가상 PC와 로컬 상황이 연결되어서 사용할 수 있게 되었다.
    3. EC2로 생성하고 연결한 가상 PC를 세팅한다.
      • 가상 PC는 방금 포맷하고 나온 컴퓨터 마냥 깨끗하다. nvm과 node.js를 설치해 주자.
      • VS Code를 다운로드한다던지 하는 이상한 짓은 하지 말자. 그래픽은 지원해 주지 않는다. 깔리기는 한다. 하지만 볼 수 없을 것이다. 볼 수 있는 부분은 CLI상황인 '터미널' 뿐이다.
      • 서버도 실행시켜 보자. 물론, 접속은 아직 안된다.
    4. EC2로 생성하고 연결한 가상 PC의 보안 그룹(Security Group)의 설정을 바꿔준다.
      • 들어오는 트래픽은 '인바운드', 나가는 트래픽은 '아웃바운드'라고 한다.
      • 아웃바운드 규칙은 상관없다. 나가는 트래픽을 막을 필요가 없다. 이미 모든 규칙이 허용되고 있을 것이다.
      • 인바운드 규칙이 중요하다. 그러므로 권한을 수정해서 우리의 요청을 받아 줄 수 있게 만들자.
      • 인스턴스에 설정되어 있는 보안 그룹으로 가서 인바운드 규칙을 추가한다. 설정한 포드 번호를 설정해 주고 어떤 프로토콜, 소스(IP)를 허용할 것인지를 설정한다.
      • 혼자서 연습할 때는 모든 접속을 허용하면 된다. 나 아니면 들어올 사람이 없다.
      • 원래 각각 클라이언트, 서버, 데이터 베이스가 사용하는 지정된 포트번호가 있다. 예를들어, http는 80번, https는 443번, 데이터 베이스는 3306번이다. 이러한 몇가지 지정된 포트번호가 있기 때문에 이러한 포트 번호를 설정해 주면 될 것이다.
    5. PM2를 설치해 백그라운드에서 서버가 실행된 상태로 존재하게 만든다.
      •  관리자 권한으로 실행시켜야 한다. 그러기 위해서 'authbind'를 설치해야 한다.
      • 만약, 그전에 서버를 켜서 프로세스가 이미 존 제한 다면 'pm2 ls'로 확인하고 있다면 지워라. authbind가 설치되고 난 후에 다시 authbind를 이용해 서버를 실행시켜야 관리자 권한이 있는 프로세스가 생긴다.
    6. S3를 이용해 호스팅 한다.
      • 정적 웹 페이지를 빌드(build)한다.
      • 내 로컬 상황에서 .env파일을 열어서 환경변수를 수정한다. 꼭 http://나 https://를 포함한 주소 'ec2로 생성한 퍼블릭 IPv4 DNS 주소'를 적어줘야 하고, 마지막에 '/'는 넣어서는 안 된다.
      • 이후 npm run build 명령어로 build폴더를 만들어 놓는다.
      • S3에서 버킷을 만들어 정적 웹 사이트의 호스팅을 활성화한다. 이때, '인덱스 문서'와 '오류 문서'에 index.html을 입력해 준다. 안 하면 접속 안된다.
      • 만든 버킷에 객체를 업로드한다. 아까 만들어 놓은 build 폴더 안에 있는 내용물들을 업로드하면 된다. build 폴더 자체를 업로드 하면 안 된다. 안의 내용물만 업로드한다.
      • 권한 탭에서 퍼블릭 액세스 차단을 전부 푼다. 권한도 생성기로 만들어서 알맞게 넣어준다.
    7. RDS로 DB 생성해서 서버와 연결한다.
      • RDS로 가서 데이터베이스를 생성한다.
      • 제발 마스터 암호 좀 쉬운 걸로 해라. 계속 틀리지 말고. 아직은 연습 단계이다.
      • 이후, 로컬 상황에서 알맞은 클라이언트(나는 mySql을 이용했다)로 DB 인스턴스에 접속한다.
      • 만약, 명령어를 입력하고 한참 아무런 반응이 없는 상황이 나온다면, 보안 그룹을 확인하자. 이것도 마찬가지 아까 인바운드 설정을 바꿔준 보안 그룹의 설정으로 바꿔줘야 한다. 아니면 한참 이후 오류 메시지를 볼 수 있다.
      • 이것도 위의 정해진 포트 번호라면 3306을 열어 놔야 할 것이다.
      • 데이터베이스에 연결된 후 만든 database를 확인한다.
    8. EC2로 만든 가상 컴퓨터에 환경변수 설정을 한다.
      • 먼저 서버 끄고 시작한다.
      • nano나 vim으로 직접 수정한다.
      • 좀 전에 RDS로 만든 데이터 베이스를 보면서 HOST에 데이터 베이스의 엔드포인트, USER, PASSWORD, PORT까지 알 맞게 설정한다.

    6. HTTPS 설정 하기

    1. 도메인을 만든다. 잘 찾아보면 무료로 도메인을 만들어 주는 곳도 있다! 아니면 과금해 보는 것도 좋은 경험이 되지 않을까?
    2. S3부분(작은 번호 6번)을 보고 다시 버킷을 만들어 준다. 이 부분은 거의 똑같다.
      • 빌드할 때 굳이 build 폴더를 삭제하고 하지 않아도 된다. npm run build 하면 매번 build 폴더는 삭제되고 다시 만들어진다.
      • 빌드를 새롭게 했다면 당연히 서버도 다시 껐다 켜줘야 한다.
    3. Route53으로 DNS를 설정한다.
      • 네임 서버 리스트를 도메인을 받은 사이트에 등록한다.
      • 라우팅 설정할 때 꼭 리전을 '미국 동부(버지니아 북부)'로 해야 한다.
      • CloudFront의 도메인 주소를 확인해서 잘 넣고, 사용할 주소 개수만큼 레코드를 정의한다.
    4. AWS Certificatuon을 이용해 인증서를 받아 적용한다.
      • AWS Certificatuon에 접속하자마자 리전을 '미국 동부(버지니아 북부)'로 바꿔준다. 그 이후 인증서를 요청해야 한다.
      • 인증은 꽤 걸린다. 가끔 새로고침을 누르면서 차분하게 기다린다. 다 발급이 완료된 후에 다음 단계를 할 수 있다.
    5. 이제 S3에서 지원하지 않는 https 형식의 배포를 위해 CloudFront를 이용한다.
      • S3에서 받아온 URL로 스택을 생성하고 '원본 도메인 이름'에 방금 만든 버킷의 정적 웹사이트 주소를 넣어준다.
      • CNAME에 받아온 도메인 주소들을 넣어준다.
      • 위에서 발급한 SSL 인증서를 선택해 준다.
      • React로 프로젝트를 만들었다면 에러 페이지 설정도 해준다. 404, 403 두 번 에러 페이지를 설정해 준다.
    저작자표시

    'Coding > Today I Learned' 카테고리의 다른 글

    2022.01.08(Sat.) <TypeScript의 기초>  (0) 2022.01.08
    2022.01.06(Thu.) <다시 처음으로 돌아가 알아보는 HTML 태그>  (0) 2022.01.07
    2021.09.14(Tue.) <Git을 이용한 버전관리>  (0) 2021.09.14
    2021.09.13(Mon.) <조금 더 알아보는 네트워크>  (0) 2021.09.13
    2021.09.10(Fri.) <취미로라도 알아두면 좋은 컴퓨터 하드웨어>  (0) 2021.09.10
    COMMENT
     
    1 ··· 13 14 15 16 17 18 19 ··· 41

    티스토리툴바