일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- VPN
- 도커
- 방화벽체크
- Openswan
- DevOps
- VIM
- Chef
- opsworks
- docker
- ssh
- Linux
- docker container
- QT
- window size
- 리눅스
- ssh command
- 루비
- docker registry
- VMware
- 드라이버
- golang
- AWS
- driver
- 패키지
- RUBY
- 우분투
- sudo
- docker-compose
- port
- ubuntu
- Today
- Total
목록2017/09 (7)
구리의 창고
머리글docker-ce 17.06 버전부터 Registry V1과 통신이이 기본으로 막혀있다. deprecated 예정이지만 꼭 사용해야 하는 시스템이 있으면 이 옵션을 강제로 활성화 시킬 수 있다. 이 글에서 Docker Registry 주소를 http://127.0.0.1:5000 이라고 가정하겠다.문제점이 문제가 발생하면 아래처럼 기본적으로 404 Not Found 에러가난다. 에러메시지가 좀 더 도움이 되면 좋겠지만 그렇지않다.Error response from daemon: login attempt to http://127.0.0.1:5000/v2/ failed with status: 404 Not FoundDocker API Version v1.12.0부터 기본으로 V1 사용이 비활성화되었는데..
머리글HTTP 서비스를 구축 할 때, 외부에 공개되지 않도록 하기위해 인증 시스템을 도입하는 경우를 생각해보자. HTTP 프로토콜에서 기본으로 제공하는 인증 시스템이 있는데 가장 간단한 방법은 Basic Authentication이다. 이 방법은 아이디/암호를 통해 인증을 하도록 되어있는데, 만약 TLS(HTTPS) 설정이 되어있지 않다면 plain text가 노출 돼 스니핑을 당해서 아이디/암호가 노출 됐을 때, 다른 시스템까지 보안에 취약해 질 수 있어서 위험하다. 모든 서버에 TLS를 설정하면 된다고는 하지만 속도나 비용문제 등을 생각 했을 때 항상 옳은 법은 아니다. 그래서 HTTP Digest Authentication이란 인증 방법을 사용해보려고 한다.설명HTTP Digest Authentic..
머리글AWS Lambda의 Deployment를 도와주는 훌륭한 도구가 있다. 바로 Apex다. 인증 방법 중 --profile옵션을 사용 할 경우 아래와 같은 에러가 나는 경우 해결책이다.NoCredentialProviders: no valid providers in chain. Deprecated.해결책Apex는 Golang으로 구현되어있고, 그에 따라 aws-sdk-go를 사용하여 구현되어있다. 그리고 sdk 문서에서 Credential 설정하는 법을 살펴보면 AWS_SDK_LOAD_CONFIG 환경 변수를 1로 설정해달라는 부분을 확인 할 수 있다.export AWS_SDK_LOAD_CONFIG=1
머리글AWS에서 EC2 인스턴스를 이용하다보면, public ip가 없는 private instance에 접속이 곤란한 경우가 있다. 아래는 AWS 문서에서 가져온 예시인데, 1개의 동일한 네트워크에서 일부는 public ip를 갖고 일부는 private ip만 갖는 경우, private instance는 네트워크 외부에서 직접 접속이 불가능하다. 이 경우 public instance에 접속 할 수 있다면, 터널링을 통해 private instance에 접근 할 수 있다.출처. http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_Scenario2.html 터널링VPN을 사용하면 정말 좋은 선택이겠지만, 위 구성에서 네트워크의 인스턴스 중 하나..
머리글AWS Opsworks는 Chef를 기반으로한 강력한 DevOps 도구이다. 오픈소스로 사용되는 각종 cookbook을 사용하며 AWS 인터페이스를 그대로 사용 할 수 있는 점이 큰 장점 중 하나이다. 2017년 9월 5일 당시 AWS Opsworks는 Chef11, Chef12 두 가지 버전으로 운영되고 있다. 둘 다 사용해본 생각을 간단히 정리 하려고한다.공통위에 설명한대로 Opsworks는 Chef cookbook을 기반으로 돌아간다. opsworks-agent-cli라는 프로그램이 Opsworks 대시보드에서 명령을 받아 내부적으로 custom cookbook을 업데이트하고 chef-client를 실행해준다. 차이점1. Built-in CookbookChef11과 Chef12의 가장 큰 차이..
소개Ruby에는 Mixin 구현을 위한 module이란 기능이 있다. 코드를 재활용하거나 큰 코드를 나눠서 구현해 여기 저기에서 필요한 코드를 가져올 때 유용하다. 일반적으로 class에 include 혹은 extend 해서 사용하게 되는데, 어떤 경우에 class method와 instance method가 되는지 코드를 통해 정리해보려고한다.includeclass Bar에 module Foo를 include하면 instance method foo가 된다.module Foo def foo puts "method foo" end end class Bar include Foo end Bar.new.foo # method foo Bar.foo # undefined method extendclass Bar에 ..
소개 AWS Opsworks(이하 Opsworks)의 많은 부분을 이미 안다고 가정하고 설명 할 것이다. Opsworks는 2017년 9월 1일 기준으로 Chef11과 Chef12가 함께 운영되고 있다. 두 버전 모두 Custom Cookbook을 사용 할 수 있다. Custom Cookbook을 작성하다보면 실제 Opsworks에서 생성한 Instance에서 테스트 및 디버깅을 해보고 싶은 욕구가 많이 생기는데 생각처럼 쉽지가 않다. 기본적으로 Ospworks는 opsworks-agent-cli가 내부적으로 설정 값을 읽어 chef-client를 실행하는 구조로 되어있다. Chef11과 Chef12는 그 구조가 다르므로 이 글에서는 Chef11 Custom Cookbook 디버깅 방법을 설명한다.ops..