https://www.mobile01.com/topicdetail.php?f=291&t=5107288&p=1059#10590
目前礙於已簽署的500億美金25%，1000億美金的10%，加上預計2019/1/1的2000億要提高到25%，已知的條件就是相對的不利，如果談判沒有結果，這些已經簽的關稅是不會取消的，就算有結果，應該是先口頭上的和談，這些關稅慢慢的才會拿掉，這些事我們幾星期前就都想清楚了，所以一成五的資金我就不會再多放了，我認為目前台股個股的股價算是在價值區，價格算是可口，買了放中長線會失敗的機率不太大，當初說過，如果和談後，可以再買進一些，當關稅逐一拿掉時，把資金逐漸加上5成，如果和談失敗，一成五要賣我個人不反對，要留也是可以，要留就是利用資金配置，透過時間視企業被影響的程度去加碼，目前水泥的價格，在第四季，明年第一季的獲利我想也不會太差，今年亞泥也許能賺到近4元，台泥能賺4.X元，撐到明年中除息時，亞泥也許就配回2.5~3元，台泥也許配2.8~3.2元，那時時間都來到明年下半年了，那時貿影戰對企業獲利的影響大概都表現出來了，那時再買進對於中長期也不會賠，長期也是甜美的價位。
佈局大量的資金時，一定是以"平均價位"，不要妄想，大盤最低5000點，你就想ALL IN在5000點，在下跌的過程中，你不會知道9000點是不是最低，8000點是不是最低，7000點是不是最低，6000點是不是晚低，5000點是不是最低，4000點是不是最低，在不景氣時，企業還是會獲利，會配息的，當公司股價在價值區，買到後，未來股價會回到價值區一點都不困難，重點是在等待的同時你還是有股息可以領，這和一般外資群的做法是一模一樣的，你看外資群持有15X萬張的台泥，7X萬張的亞泥，不論中美貿易戰是否持續，外資群不會出清台泥及亞泥的，了不起就是調節一些為了要打敗大盤績效或別的基金經理人的績效，當股價跌到價值區時，長期領息，你賺都賺死了，未來在景氣很好時，把股票賣出，賺了三年，五年，十年的息，還賺了差價，這才是致富的方法，每天賺0.3，0.5元，動不動就退出股市，這種人付交易稅、手續費就付到死，錢沒有買股票時就把錢放活存, 賺0.1%的利息，聰明一點的放1%的定存，但實際上比不上買進有價值的股票持有領息好，在你沒有賣出前股價不重要，你要在乎的事是公司一年能配多少殖利率給你，未來股價會不會漲上去，會不會填息，公司淨值會不會持續增加，如果會的話，股價其實不用太在意。
我這樣說好了，你買在台泥、亞泥十年線的位置，意謂著股價平均就在這，貿易戰下，今年賺的錢還是會分股息，明年獲利就算減半，殖利率還是會有3~4%，當股息一直配時，公司還是會賺錢，雖然股價因一時的預期心理或景氣不好而修正，此時股價會就隨著發放股息愈多年股價愈低，當景氣回升時，股息照發，股價回到十年線以上，應該不難吧，畢竟你買在十年均線下，一些來說，景氣好時，股價都會距離十年線上面非常的遠，在景氣不好時，公司獲利或價值還在，你就能持續的加碼，最終出在景氣最好時，這也是為什麼很多人想要股市崩盤買進十年的起漲點，因為他們知道，買在這個點抱十年，不但能賺到十年的股息，還能賺到差價，賺到一次差不多就財富自由了。
https://sukbeta.github.io/2018/11/21/ES-%E8%A7%A3%E5%86%B3-memory-lock-%E9%97%AE%E9%A2%98/
check
http://xxx.xxx.xxx.xxx:9200/_nodes?filter_path=**.mlockall
My way
services: elasticsearch: build: context: elasticsearch/ volumes: - ./elasticsearch/esdata:/usr/share/elasticsearch/data:rw - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro ports: - "9200:9200" - "9300:9300" environment: - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 networks: - elk
http://sueboy.blogspot.com/2018/11/docker-iptables_12.html
sudo iptables -vnL
======NAT=====
sudo iptables -t nat -vnL
顯示行數
sudo iptables -t nat -L POSTROUTING -n –line-numbers
-D 刪除那行
sudo iptables -t nat -D POSTROUTING x x is which line delete
確認docker網段補上
sudo iptables -t nat -A POSTROUTING -s 172.19.0.0/16 ! -o docker0 -j MASQUERADE
https://www.centos.bz/2018/02/%E5%AE%9A%E5%88%B6entrypoint%E8%87%AA%E5%8A%A8%E4%BF%AE%E6%94%B9docker%E4%B8%ADvolume%E7%9A%84%E6%9D%83%E9%99%90/
……….
Other way
1、make shell and run shell, before run docker-compose.
mkdir ./data sudo chown docker ./data #sudo chown user01 ./data sudo chmod g+rwx ./data sudo chgrp 994 ./data Directory exist and correct Access. 994 or 50 or 1000 see /etc/passwd or /etc/group
2、But sometime OS install docker by you don’t know way… maybe have user dockerroot、group dockerroot or only group docker
you maybe already run sudo usermod -a -G docker $(whoami) 100% in docker group.
https://segmentfault.com/a/1190000009540007
WebApp场景下的隐患
举个我曾经在另一篇博客中提到过的例子，一个业务流程有三个页面A/B/C，用户通常按顺序访问它们，每步都会提交一些信息，如果把信息存在Store中，在不刷新的情况下C页面可以直接访问A/B页面存进Store的数据，而一旦用户刷新C页面，这些数据便不复存在，使用这些数据很可能导致程序异常。
它可以从两方面缓解上述问题：
抽象问题：每个Page独立创建store，解决状态树的一对多问题，一个状态树(store)对应一个组件树(page)，page在设计store时不用考虑其它页面，仅服务当前页。当然，由于Reducer仍然需要独立于组件树声明，抽象问题并没有根治，面向领域数据和App state的抽象仍然比UI state更自然。它仅仅带给你更大的自由度：不再担心有限的状态树如何设计才能满足近乎无限的UI state。 刷新、分享隐患：每个Page创建的Store都是完全不同的对象，且只存在于当前Page生命周期内，其它Page不可能访问到，从根本上杜绝跨页面的store访问。这意味着能够从store中访问到的数据，一定是可靠的。 2017.08.27 更新
这个方案在实践中，仍然遇到了一些问题，其中最最重要的，则是替换store后，跨页面action的问题
为了应对这个问题，我考虑了几种方案：
回到应用单一store：pageReducer的特性通过store.replaceReducer完成。当初为每个页面创建store是想让状态彻底隔离，而在replaceReducer后页面之间如果有相同的reducer则状态不会被重置，这是一个担心点。同时一个副作用是牺牲掉每个page定制化middleware的能力 为这类跨页面的action建立一个队列，在上个页面将action推进队列，下个页面取出再执行。此方案属于头痛医头，只能解决当前的case，对于websocket等类似问题比较无力。 定制thunk middleware，通过闭包获取最新的store 在权衡方案的通用性、理解难度等方面后，目前选择了第一种。
Now check again….
1、template_filebeat.json
Can only
{ "index_patterns": ["filebeat*"], "settings": { "number_of_shards": 1 }, "mappings": { "doc": { "properties": { "geoip.location": { "type": "geo_point" }, "geoip.coordinates": { "type": "geo_point" } } } } } Here Import： “location” is Error, Must “geoip.location”
But sometime why no use, because my way insert index-pattern, so geoip.location no field, always is
geoip.location.lat and geoip.location.lon overwrtie.
see 2.
2、index-pattern index-pattern-export.json
one way just try to put
Filebeat + Elasticsearch + Kibana 轻量日志收集与展示系统
https://wzyboy.im/post/1111.html?utm_source=tuicool&utm_medium=referral
提到
beat -> logstash -> elk
可以
beat -> elk ingest plugs ( Elasticsearch Ingest Node )
Elasticsearch Ingest Node 是 Elasticsearch 5.0 起新增的功能。在 Ingest Node 出现之前，人们通常会在 ES 前置一个 Logstash Indexer，用于对数据进行预处理。有了 Ingest Node 之后，Logstash Indexer 的大部分功能就可以被它替代了，grok, geoip 等 Logstash 用户所熟悉的处理器，在 Ingest Node 里也有。对于数据量较小的 ES 用户来说，省掉一台 Logstash 的开销自然是令人开心的，对于数据量较大的 ES 用户来说，Ingest Node 和 Master Node, Data Node 一样也是可以分配独立节点并横向扩展的，也不用担心性能瓶颈。
目前 Ingest Node 已支持数十种处理器，其中的 script 处理器具有最大的灵活性。
与 /_template 类似，Ingest API 位于 /_ingest 下面。用户将 pipeline 定义提交之后，在 Beats 中即可指定某 pipeline 为数据预处理器。
