Author Archives: archmagece

sudo without password

https://askubuntu.com/questions/334318/sudoers-file-enable-nopasswd-for-user-all-commands


https://zetawiki.com/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_sudo_%ED%8C%A8%EC%8A%A4%EC%9B%8C%EB%93%9C_%EC%97%86%EC%9D%B4_%EC%82%AC%EC%9A%A9

/etc/sudoers를 편집해버리기

#includedir /etc/sudoers.d 뒤에다가

사용자명 ALL=NOPASSWD: ALL
사용자명 ALL=(ALL) NOPASSWD:ALL

두가지 스타일 다 먹히는듯하다.

/etc/sudoers.d에 추가하기

왜 에러날까..

실패시

usb넣고 라이브윈도우 부팅해서 들어가서 수정

람다는 쉽다며 씨발

개삽질 기간포함 일주일 좀 넘게 걸린 것 같다.

1단계 Go로 HelloWorld

처음엔 go언어 이용해서 간단하게

2단계 외부연동 GW

GW설정을 해야되는군… 뭐가 씨발 되다말다 하고
DTO구성을 바꿔줬다

3단계 RDS 연결

같은 VPC를 써야하는군..
iam인증을 쓰면 커넥션 생성속도가 느리다고?
타임아웃은 왜 계속 나오는거지
vpc에서 시큐디티 그룹을 연결시켜줘야 하는군
아이피는 왜 자꾸 변하는데… vpc전역(172.1.0.0/16)을 오픈 해 놔야하는건가
커넥션 풀은 어떻게 하지? 일단 패스

4단계 SNS 호출

제대로 한 것 가튼데
로컬에서 호출이 되는데
아 왜 안되지
머리가 마비된다
event trigget – sns to lambda는 많은데 lambda to sns자료는 잘 없다.
엔드포인트 생성(https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpce-interface.html)
(https://docs.aws.amazon.com/ko_kr/sns/latest/dg/sns-vpc-endpoint.html)

셋팅하고나서 좀 있으면… 된다.

Go 언어 사용 감상 – Generic이 없다는 것…

새로운 언어를 공부할 때 언어별 특성에 따라 다른 접근방법을 사용해야한다.
요즘은 Go언어로 뭘좀 해 보려고 했는데…

언어의 특성 때문에 yaml의 설계마저도 달라져야 한다는 것을 알게 됐다.
(내가 너무 자바스타일로 구조를 잡는건지도 모르겠다

간단한 빌드 툴을 만들면서 아래와 같은 형태의 제네릭 리스트를 yaml로 만들었는데

  • DockerWork
    • Dockerimage
    • Dockerrepo
    • Dockerfile

당연하다는 듯이 제네릭?오브젝트리스트? 형태로 만들어 버렸다.
Go언어를 잘 못해서 그런것일 수도 있는데 뭔가 만들기가 난감하다.
제네릭이 필요했는데 Go언어에는 그게 없었다.
커뮤니티 검색도 좀 해봤는데 generic 지원을 요청하는 이슈가 많았지만
고언어에는 그게 필요없다~ 라는 의견으로 마무리

강타입에 정적타입이면서 generic이 없다니…

위의 문제를 해결할 때
자바 – 제네릭,
파이썬 – 오브젝트리스트
C언어 – !!노개다
Go언어 – !!노가다
아마 다른언어는 다 비슷한 스타일일거다.

Go언어는 C언어에 가까운 해결방법을 찾으라는 것 같다.
python처럼 is type체크를 하고 형변환 없이 사용할 수 있다면 또 모르겠는데..
그게 아니니 더 난감하다.

뭔가 편하고 깔끔한 방법이 있는데 못 찾는건지.. 아마 없을 것 같다.
덕타이핑과 인터페이스 ifelse 떡칠이 답일 것 같다.

말 나온김에 덕타이핑도…
Duck typeing 덕분에 발생하는 복잡함

다음과 같은 코드가 있다면

type Writer interface {
Write(p []byte) (n int, err error)
}


자바할 때 처럼 이 인터페이스의 이름을 찾는다면?
나올수도 있고 안 나올수도 있다.

덕타이핑이라고

구현체 사이에 의존관계가 없기 때문에 레퍼런스 검색이 힘들다
동일한 패턴의 인터페이스를 몽땅 검색해야 되는데
자바 개발을 하던 습관이 남아서 그런지 좀 난감하다.

장점일 수도 있고.. 단점일 수도 있는 이 부분..
상속이 없는 것도 덕타이핑의 일부 특성이라고 봐야할 것 같다

기본 문법도 쉽고 간단한 코드를 만들기도 쉽지만
언어 자체가 쉽다?? 글쎄….
데이터 구조를 다루기 힘든 언어인지 익숙해지지 않아서인지…

고 언어 후기

  • 간단한 코드를 짜기는 쉬울 것 같다.
  • 실행 속도가 빠르다? 글쎄…
  • 실행파일을 만들어서 설치하기 쉽다

무료 기업용?도메인 이메일 주소 서비스yandex

미제의 패악질을 참지 못한 불곰 형님들이 무료 도메인 서비스를 개시했다. 서비스 개 후진 양아치 네이버나 착하지만 서비스는 더 꾸진 다음하고 비교대상이 아니다.
그럭저럭 쓸만한 메일플러그와 같은 국내 서비스도 있긴한데..

회사 운영하는 것도 아니고 개인용으로 쓸만한 적당한 계정을 찾다보니 yandex라는 러시아 포탈서비스를 찾았다.

여윾시 글로벌 시대랄까…

10년후엔 아프리카 서비스를 쓰게 될지도 모르겠다.
아프리카 서비스는 유럽 제국주의자들 덕분에 편하게 쓰겠군..

사용법은… 그냥 매우 쉽다.

yandex.com 에서 가입하고
https://connect.yandex.com/pdd/
여기서 도메인 추가 해 주면 된다.

  1. TXT 관리에다가 뭐 좀 써주고
  2. MS정보랑 SRV. CNAME 써주면 완료

[도서] RxJava를 활용한 리액티브 프로그래밍

왜?

보통은 개발을 하다가 필요하다고 생각되는 기능을 검색하거나
기술블로그를 보면서 재밌어 보이거나 필요해 보이는 것들을 찾아서 공부하는데
RxJava는 별로 필요성이 안 느껴져서 관심을 갖지 않았다.

그냥 Reactive 프로그래밍을 가능하게 해주는 프레임워크?로
GUI프로그래밍 할 때나 사용하겠지 … 하고 말았었다.
개인적으로는 웹개발을 하면서는 쓰레드나 Callback 지옥을 경험해본 일이 없어서..
여러 시스템에 연동하는 복잡한 서비스를 만드는 경우에는 사용하면 좋으려나

— 좀 다른 얘기지만 저번에 어느 회사 면접볼 때 Observer Pattern 얘기가 나왔을 때 눈똥그래져서 물어보시던데.. RxJava를 아는지 체크 해 본려고 했던건가

키워드 및 요약정보

자바와 안드로이드를 위한 리액티브 프로그래밍 구현체
함수형 프로그래밍의 영향
비동기 이벤트 기반 프로그램 – 스트림 방식
서버에도 적용

Rx(ReactiveExtension) 함수형프로그래밍에 영향을 받았지만 FRP(Functinoal Reactive Programming)은 아니다.
Observable/Observer<T>
Producer
Subscription/Subscriber<T>


포기.. 무슨 클래스 메서드 하나하나 다 설명을 해놨는데
안그래도 텍스트로 소스보면 몇배나 더 걸리는데 하나하나 보려면 한달은 걸리겠다.
그래서
1~2단원 앞쪽 개념설명과 인덱스만 훑어보고 넘어간다.
중요한 부분만 뽑아서 보고싶은데 편집이 불친절해서 골라먹기도 힘들게 돼 있다.
아예 필요없는 책이라고는 못하겠는데 좀 어려운 것 같다.
RxJava Getting Started같은 문서나 보고 그냥 쓰다가
필요성이 느껴질 때 다시 봐야겠다.

Docker Volume 중첩해서 셋팅하는 경우 발생하는 문제 확인

초기 디렉토리 구조 생성

➜  $ tree
 .
 ├── test1
 │   ├── test1
 └── test2
     └── test2
$ cat test1/test1
test1 file
$ cat test2/test2
test2 file

도커에서 볼륨을 셋팅하고 실행

$ docker run --rm -it \
-v $(pwd)/test1:/test \
-v $(pwd)/test2:/test/kkk \
-v $(pwd)/test2/test2:/test/test2file \
-v $(pwd)/test1/test1:/test/test1file \
-v $(pwd)/test2:/test/kkk1 \
alpine sh

도커 실행 후 HOST에서 봤을 때 변경된 파일구조

$ tree
 .
 ├── test1
 │   ├── kkk
 │   ├── kkk1
 │   ├── test1
 │   ├── test1file
 │   └── test2file
 └── test2
     └── test2

도커 실행 후 Container 내부에서 변경된 파일구조

# tree
 .
 ├── kkk
 │   └── test2
 ├── kkk1
 │   └── test2
 ├── test1
 ├── test1file
 └── test2file

volume 마운트 시켰는데 파일이 복사돼버림

중복된 마운트를 할 경우 생각과 다르게 동작할 가능성

마이크로서비스 아키텍처 구축 대용량 시스템의 효율적인 분산 설계 기법, 한빛미디어

몇달쯤 전에 처음 볼 때는 뭐 당연한걸 책으로 써놨네~ 하면서 대충 훑어보고 말았는데
최근 MSA 관련 작업을 하면서 다시 보게 됐다.

다시 보니까 전에 못 보던 부분도 보이고 전체적인 흐름도 잘 정리되서 좋았다.

MSA 관련기술

DevOps 관련 플로우

  • 빌드시 유닛테스트
  • CI/CD
    • pull request 하면서 유닛테스트
    • 통과시 container build
      – 이미지에 로깅 툴을 넣어서배포
    • stg(staging) 배포
  • 통합테스트(수동?또는자동)
  • prd(production) 배포

예전에 제대로 모르고 넘어간 요소들

API GW(zuul), CircuitBreaker(hystrix), ServiceDiscovery(eureka), ClientLoadbalancer(ribbon)

넷플릭스쪽이 관련 인프라가 잘 돼 있어서 spring쪽 개발자는 그걸 참고하면 편하다.

MSA적용실패사례 – MSA vs Monolith

예전에 O2O 서비스를 만들 때도 SOA를 시도했다가 실패했는데
모놀리스형태로 만들어야 할 규모의 서비스를 무리하게 분할한게 원인이었다.

처음에 사용자별로 서비스를 나눈 것 까지는 좋았다.

  • 사용자ROLE별로 구분된 웹서버
    • 일반사용자
    • 관리자
    • 사장님
  • 인증서버
  • APP api서버

그런데 여기서 일부 기능을 떼서 서비스 지역정보, 메일문자전송, 다국어관리, … 이렇게 넣다보니 일이 너무 많아졌다.

DevOps도 처음 적용해서 여기저기 오류 터지는데 서비스 개발까지 하려니 죽어났다.

MSA 적용 실패요인

인력부족, 기술부족, 자금부족

MSA를 제대로 이해하고 있고 관련기술을 구성할만한 사람이 있어야된다.
연구하면서 진행하려면 서비스 개발 이외에 최소 서너명이 더 있어야 하지 않을까

서비스 변화

MSA는 서비스 목표가 확실해진 이후에 해야되는 것 같다. 전체적인 서비스 구조는 고정 되어 있고 기능을 추가하기 좋다는거지 서비스의 큰 흐름이 변하는 경우에는 절대로 쓰면 안된다.

초기 스타트업은 서비스 하다가 버리고 다시 시작하기도 하고 메인 기능이 막 바뀌고 추가되고 하니까 MSA에 적합하지 않다.

~

개발자라면 한번쯤 보는게 좋을 것 같다.

요즘 대부분 서비스가 MSA화 되어가고 있고 이정도 속도면 10년안에 국가프로젝트도 MSA적용이 일반화될 것 같으니까

자바9 모듈프로그래밍, 한빛미디어

자바9의 모듈화(jigsaw) 개념을 중심만 다뤘다.

간단하다
소스루트에다가 module-info.java파일을 생성해서
module{}을 정의하고
requires, exports.. 외 몇가지 구문으로 정의하는것.

typescript같은 언어에서 export 선언한 것만 접근할 수 있는것처럼

 

이 책의 내용은 이게 전부다. 모듈화에만 집중해놔서
자세한 정보는 : http://openjdk.java.net/projects/jigsaw/quick-start

실전적용

라이브러리 개발의 경우에는 캡슐화에 신경쓰려면 세부적인 설정을 해야겠지만
일반적인 서비스모듈 개발에는 현재와 별 차이는 없을 것 같다.
maven/gradle에서 좀 더 신경쓸게 생기겠지만

gradle의 한개 모듈마다 module-info.java를 한개씩 갖게 된다.
jar파일 한개당 한개의 module이라고 생각하면 된다.

기타 책들

가장 빨리 만나는 코어 자바9: 자바9으로 배우는 모던 자바, 길벗
도 같이 봤는데.. 이건 두꺼우면서 쓸데없는 내용이 잔뜩 있고
막상 중요한 부분은 짧게 설명이 돼 있어서 제대로 보지 않았다.

자바9에서 변하는 점

구조적으로 큰 변화인지는 모르겠지만 개발하는 입장에서는 코드상에 큰 변화는 없다.

gradle에 mysql.jar을 가져와서 ide에서는 com.mysql.Driver이 검색되는데 프로젝트에서는 빨간불이 뜨는 상황은 좀 더 자주 보게 되겠지만.

어차피 지금도 gradle 모듈로 프로젝트 나눠서 개발하는 사람은 거의 변화를 못 느끼지 않을까

~

어차피 금방 보니까 한번 보면 좋지 않을까

혹시 다른내용이 있나 싶어서 꼼꼼히 읽다가 몇시간 지났는데 별거 없으니 그냥 훑어보면 될 것 같다. 아니 그냥 공식도큐먼트랑 블로그만 몇 개 봐도 되려나