일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Google Cloud Platform
- cloud function
- terraform
- VAGRANT
- pub/sub
- IAM
- gcp
- MIG
- cloud armor
- Uptime Check
- 자격증
- Terraform Cloud
- vm
- 우테캠
- Java
- interconnect
- devops
- cloud
- github
- AWS
- direnv
- CentOS
- Clean Code
- 후기
- docker
- Python
- cicd
- 보안 규칙
- kubernetes
- vpc peering
- Today
- Total
목록github (3)
EMD Blog
Terraform Cloud에서 VCS 연결 시 팀별 액세스 권한 설정이 안되는 이슈가 있음. 테스트 내용은 아래와 같음. team 내 member 역할이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 team 내 maintainer 역할이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 organizations 내 소유자 원한이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 알고 보니 OAuth 연동 시 조직 repository 액세스 권한을 체크 해줘야했음. 만약 조직의 소유자라면 그냥 체크만 하고 넘어가면 되지만 조직 member라면 소유자에게 액..
회사 프로젝트 중 크롤링 Batch 서버를 구축해야할 일이 생겼다. 새롭게 들어온 팀원이 맡아서 진행하기로 했는데 기왕 하는 거 Docker Image push 까지 자동화 구축 후 진행을 하면 좀 더 편하게 개발을 하지 않을까 싶어 구축 과정을 간략하게 기록하려한다. 사내 서비스 운영은 인력 부족 및 금액 적인 부분 때문에 AWS에 많이 의존하고 있다. 현재 구축하려는 서비스도 MongoDB를 활용하려다가 데이터가 쌓이면 관리하기 힘들어질 것 같아 DynamoDB를 활용하기로 했다. 구축하고자 하는 개발 프로세스는 다음과 같다. 먼저 로컬에서 github repository를 remote하여 개발하다가 이슈 단위의 작업이 종료되면 Github의 Task branch에 Push 후 develop bran..
이슈관리 현재 사내에서는 원격 Git repository로 Github를 채택해서 사용하고 있다. 현재 구성원은 백엔드 개발 2명 프론트개발 1명이 맡아서 하고 있고 각 개발자들은 자신들이 맡은 영역을 개발하고 있으며 겹치는 부분이 있지는 않아 협업으로서의 Git사용을 하고 있지는 않다. 그래서 Git을 코드 관리 측면에서만 계속 사용하고 있었고 간단하게 Branch 관리만 하면서 작업을 진행하고 있었다. 하지만 개발이 진행됨에 따라 출시 이후 버전 관리라던가 개발 및 배포 프로세스를 어떻게 잡을 것인지 주기는 어떻게 할 것인지 등 다양한 문제를 생각하지 않을 수 없게 되었다. 사실 개발을 시작했을 때부터 고민하고 잡고 갔어야했을 문제였지만 사정이 여의치 않다는 핑계를 대면서 미뤄왔었고 이제 간단하게 나..