| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- pub/sub
- 자격증
- kubernetes
- interconnect
- cloud function
- 후기
- gcp
- cicd
- github
- Java
- 보안 규칙
- terraform
- Google Cloud Platform
- AWS
- VAGRANT
- Python
- vm
- 우테캠
- MIG
- cloud
- Terraform Cloud
- CentOS
- Uptime Check
- Clean Code
- cloud armor
- IAM
- direnv
- vpc peering
- devops
- docker
- Today
- Total
목록AWS (12)
EMD Blog
AWS를 사용하여 진행하며 요금이 과금될 수도 있습니다. 주의바랍니다. 꼭 AWS를 사용하지 않아도 다른 개인 서버(Local도 괜찮습니다.)를 사용해도 됩니다. Jenkins를 이용한 배포 자동화 이번에는 배포 자동화를 구현 해보자. 배포 자동화에 사용될 도구는 대표적인 CI 도구 중 하나인 Jenkins를 활용하도록 하겠다. 배포 프로세스는 이렇다. 먼저 개발을 하고 Commit 후 Github Repository의 Master로 Push를 하게 되면 Github에서는 WebHook을 통해 Jenkins에게 Push 이벤트를 보내고 Jenkins는 서버에 코드를 배포하게 된다. 서버는 AWS를 이용해서 진행하도록 하겠다. 먼저 Jenkins 서버로 사용할 EC2를 생성하자. 원래는 CentOS를 주로..
기존 구축되어 있던 환경을 Cloud로 Migration하는 것은 많은 생각을 하게 만든다. 특히 경험이 많은 시니어 개발자가 이끌어 주는, 혹은 이미 기존에 존재하던 대규모 시스템에 적용되어 있는 규칙을 따를 수 있는 상황이 아니라면 앞으로 구축할 인프라에 대한 걱정이 앞설 수 밖에 없다. 이제는 개발된 서비스의 방향성과 그에 따른 아키텍처, 인프라 구축에 대한 설계가 어느정도 끝이 나고있고 이제는 그에따라 구축만 하면되는 상황이지만 서비스 규모가 커지고, 개발자 인원이 늘어날 경우 리소스들이 스파게티 처럼 엉켜 처치불가한 상태가 될 수 있다. AWS에서는 이런 상황에 대한 다양한 해결법을 제시해 주고 있지만 우리는 먼저 가장 간단하게 바로 적용할 수 있는 리소스들의 Naming 규칙을 정해 도입해보는..