腾讯推送的新闻：电梯吃人时间，过程仅9秒，在最后时刻母亲将儿子推到安全地带
看完新闻后，我内心再一次震撼。
我又一次感动，感动母亲的伟大，但是我不喜欢这种感动，因为这是以生命为代价的。
同时我也感到生命的渺小，生命的脆弱。
最后，我很想说，只要大家不对生命再进行漠视，对自己的工作负责任。
相信悲惨的时间会发生少一些。
最后，祝那位母亲能够安息！
最后，我想说，这个社会不仅仅需要良心的谴责，更需要有严重的惩罚！
2015年1月20日星期二
I am only a user ,not a developer
如果你和我一样，那么你很早就开始利用HTML进行“开发”，正因如此，你接触到了这个叫JavaScript有趣的东西，而对于JavaScript，你只会基本的操作——为web页面添加交互。
而你真正想要的是“干货”，你想要知道如何构建复杂的web站点 —— 于是，你学习了一种诸如PHP、Ruby、Java这样的编程语言，并开始书写“后端”代码。
与此同时，你还始终关注着JavaScript，随着通过一些对jQuery，Prototype之类技术的介绍，你慢慢了解到了很多JavaScript中的进阶技能，同时也感受到了JavaScript绝非仅仅是window.open() 那么简单。 .
不过，这些毕竟都是前端技术，尽管当想要增强页面的时候，使用jQuery总让你觉得很爽，但到最后，你顶多是个JavaScript用户，而非JavaScript开发者。
这句话让我认识到我自己的浅薄，原以为自己能够调用类库，就是开发者了，才知道自己不过是一个使用者而已，而使用者和开发者所最大的区别，我个人感觉开发者更有创造的思想和能力。
2015年1月19日星期一
Kubernetes Design Overview(reprinted)
Kubernetes Design Overview
Overview
Kubernetes is a system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. Its APIs are intended to serve as the foundation for an open ecosystem of tools, automation systems, and higher-level API layers.
Kubernetes uses Docker to package, instantiate, and run containerized applications.
Is Kubernetes, then, a Docker "orchestration" system? Yes and no.
Kubernetes establishes robust declarative primitives for maintaining the desired state requested by the user. We see these primitives as the main value added by Kubernetes. Self-healing mechanisms, such as auto-restarting, re-scheduling, and replicating containers require active controllers, not just imperative orchestration.
Kubernetes is primarily targeted at applications comprised of multiple containers, such as elastic, distributed micro-services. It is also designed to facilitate migration of non-containerized application stacks to Kubernetes. It therefore includes abstractions for grouping containers in both loosely coupled and tightly coupled formations, and provides ways for containers to find and communicate with each other in relatively familiar ways.
Kubernetes enables users to ask a cluster to run a set of containers. The system automatically chooses hosts to run those containers on. While Kubernetes's scheduler is currently very simple, we expect it to grow in sophistication over time. Scheduling is a policy-rich, topology-aware, workload-specific function that significantly impacts availability, performance, and capacity. The scheduler needs to take into account individual and collective resource requirements, quality of service requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, deadlines, and so on. Workload-specific requirements will be exposed through the API as necessary.
Architecturally, we want Kubernetes to be built as a collection of pluggable components and layers, with the ability to use alternative schedulers, storage systems, and distribution mechanisms, and we're evolving its current code in that direction.
Kubernetes is intended to run on multiple cloud providers, as well as on physical hosts.
A single Kubernetes cluster is not intended to span multiple availability zones. Instead, we recommend building a higher-level layer to replicate complete deployments of highly available applications across multiple zones.
Kubernetes is not currently suitable for use by multiple users -- see Cluster Security, below.
Cluster Architecture
A running Kubernetes cluster contains node agents (kubelet) and master components (APIs, scheduler, etc), on top of a distributed storage solution. This diagram shows our desired eventual state, though we're still working on a few things, like making kubelet itself (all our components, really) run within docker, and making the scheduler 100% pluggable.
Key Concepts
While Docker itself works with individual containers, Kubernetes provides higher-level organizational constructs in support of common cluster-level usage patterns, currently focused on service applications, but which could also be expanded to batch and test workloads in the future.
Pods
A pod (as in a pod of whales or pea pod) is a relatively tightly coupled group of containers that are scheduled onto the same host. It models an application-specific "virtual host" in a containerized environment. Pods serve as units of scheduling, deployment, and horizontal scaling/replication, share fate, and share some resources, such as storage volumes and IP addresses.
Labels
Loosely coupled cooperating pods are organized using key/value labels.
Individual labels are used to specify identifying metadata, and to convey the semantic purposes/roles of pods of containers. Examples of typical pod label keys include
service, environment (e.g., with values dev, qa, orproduction), tier (e.g., with values frontend or backend), and track (e.g., with values daily or weekly), but you are free to develop your own conventions.
Via a label selector the user can identify a set of pods. The label selector is the core grouping primitive in Kubernetes. It could be used to identify service replicas or shards, worker pool members, or peers in a distributed application.
Kubernetes currently supports two objects that use label selectors to keep track of their members,
services andreplicationControllers:service: A service is a configuration unit for the proxies that run on every worker node. It is named and points to one or more pods.replicationController: A replication controller takes a template and ensures that there is a specified number of "replicas" of that template running at any one time. If there are too many, it'll kill some. If there are too few, it'll start more.
The set of pods that a
service targets is defined with a label selector. Similarly, the population of pods that areplicationController is monitoring is also defined with a label selector.
For management convenience and consistency,
services and replicationControllers may themselves have labels and would generally carry the labels their corresponding pods have in common.The Kubernetes Node
When looking at the architecture of the system, we'll break it down to services that run on the worker node and services that comprise the cluster-level control plane.
The Kubernetes node has the services necessary to run Docker containers and be managed from the master systems.
The Kubernetes node design is an extension of the Container-optimized Google Compute Engine image. Over time the plan is for these images/nodes to merge and be the same thing used in different ways. It has the services necessary to run Docker containers and be managed from the master systems.
Each node runs Docker, of course. Docker takes care of the details of downloading images and running containers.
Kubelet
The second component on the node is called the
kubelet. The Kubelet is the logical successor (and rewritten in go) of the Container Agent that is part of the Compute Engine image.
The Kubelet works in terms of a container manifest. A container manifest (defined here) is a YAML file that describes a
pod. The Kubelet takes a set of manifests that are provided in various mechanisms and ensures that the containers described in those manifests are started and continue running.
There are 4 ways that a container manifest can be provided to the Kubelet:
- File Path passed as a flag on the command line. This file is rechecked every 20 seconds (configurable with a flag).
- HTTP endpoint HTTP endpoint passed as a parameter on the command line. This endpoint is checked every 20 seconds (also configurable with a flag.)
- etcd server The Kubelet will reach out and do a
watchon an etcd server. The etcd path that is watched is/registry/hosts/$(hostname -f). As this is a watch, changes are noticed and acted upon very quickly. - HTTP server The kubelet can also listen for HTTP and respond to a simple API (underspec'd currently) to submit a new manifest.
Kubernetes Proxy
Each node also runs a simple network proxy. This reflects
services (see here for more details) as defined in the Kubernetes API on each node and can do simple TCP and UDP stream forwarding (round robin) across a set of backends.
Service endpoints are currently found through environment variables (both Docker-links-compatible and Kubernetes {FOO}_SERVICE_HOST and {FOO}_SERVICE_PORT variables are supported). These variables resolve to ports managed by the service proxy.
The Kubernetes Control Plane
The Kubernetes control plane is split into a set of components, but they all run on a single master node. These work together to provide a unified view of the cluster.
etcd
All persistent master state is stored in an instance of
etcd. This provides a great way to store configuration data reliably. With watch support, coordinating components can be notified very quickly of changes.Kubernetes API Server
This server serves up the main Kubernetes API.
It validates and configures data for 3 types of objects:
pods, services, and replicationControllers.
Beyond just servicing REST operations, validating them and storing them in
etcd, the API Server does two other things:- Schedules pods to worker nodes. Right now the scheduler is very simple.
- Synchronize pod information (where they are, what ports they are exposing) with the service configuration.
Kubernetes Controller Manager Server
The
replicationController type described above isn't strictly necessary for Kubernetes to be useful. It is really a service that is layered on top of the simple pod API. To enforce this layering, the logic for the replicationController is actually broken out into another server. This server watches etcd for changes to replicationController objects and then uses the public Kubernetes API to implement the replication algorithm.GCE Cluster Configuration
The scripts and data in the
cluster/ directory automates creating a set of Google Compute Engine VMs and installing all of the Kubernetes components. There is a single master node and a set of worker (called minion) nodes.config-default.sh has a set of tweakable definitions/parameters for the cluster.
The heavy lifting of configuring the VMs is done by SaltStack.
The bootstrapping works like this:
- The
kube-up.shscript uses the GCEstartup-scriptmechanism for both the master node and the minion nodes.- For the minion, this simply configures and installs SaltStack. The network range that this minion is assigned is baked into the startup-script for that minion (see the networking doc for more details).
- For the master, the release files are staged and then downloaded from GCS and unpacked. Various parts (specifically the SaltStack configuration) are installed in the right places. Binaries are included in these tar files.
- SaltStack then installs the necessary servers on each node.
- The custom networking bridge is configured on each minion before Docker is installed.
- Configuration (like telling the
apiserverthe hostnames of the minions) is dynamically created during the saltstack install.
- After the VMs are started, the
kube-up.shscript will callcurlevery 2 seconds until theapiserverstarts responding.
kube-down.sh can be used to tear the entire cluster down. If you build a new release and want to update your cluster, you can use kube-push.sh to update and apply (highstate in salt parlance) the salt config.Cluster Security
As there is no security currently built into the
apiserver, the salt configuration will install nginx. nginx is configured to serve HTTPS with a self signed certificate. HTTP basic auth is used from the client to nginx. nginx then forwards the request on to the apiserver over plain old HTTP. As part of cluster spin up, ssh is used to download both the public cert for the server and a client cert pair. These are used for mutual authentication to nginx.
All communication within the cluster (worker nodes to the master, for instance) occurs on the internal virtual network and should be safe from eavesdropping.
The password is generated randomly as part of the
kube-up.sh script and stored in ~/.kubernetes_auth.2014年12月19日星期五
on windows oracle monitoring service has not started successfully
Q: the oracle is installed on the Windows system, the service is set to automatically start, but when system starts, oracle monitoring service has not started successfully
Answer: a disguised form of the solution, using plan task start, start the script as follows:
@ echo off
Ping - 10 127.0.0.1 n > nul
Sc start OracleOraDb11g_home1TNSListener > nul
The Exit
@ echo on
Answer: a disguised form of the solution, using plan task start, start the script as follows:
@ echo off
Ping - 10 127.0.0.1 n > nul
Sc start OracleOraDb11g_home1TNSListener > nul
The Exit
@ echo on
2014年10月22日星期三
Linux有问必答：如何在CentOS7上改变网络接口名
传统上，Linux的网络接口被枚举为eth[0123...]，但这些名称并不一定符合实际的硬件插槽，PCI位置，USB接口数量等，这引入了一个不可预知的命名问题（例如，由于不确定的设备探测行为），这可能会导致不同的网络配置错误（例如，由无意的接口改名引起的禁止接口或者防火墙旁路）。基于MAC地址的udev规则在虚拟化的环境中并不有用，这里的MAC地址如端口数量一样无常。
CentOS/RHEL6引入了一致和可预测的网络设备命名网络接口的方法。这些特性可以唯一地确定网络接口的名称以使定位和区分设备更容易，并且在这样一种方式下，无论是否重启机器、过了多少时间、或者改变硬件，其名字都是持久不变的。然而，这种命名规则并不是默认在CentOS/RHEL6上开启。
从CentOS/RHEL7起，这种可预见的命名规则变成了默认。根据这一规则，接口名称被自动基于固件，拓扑结构和位置信息来确定。现在，即使添加或移除网络设备，接口名称仍然保持固定，而无需重新枚举，和坏掉的硬件可以无缝替换。
* 基于接口类型的两个字母前缀: * en -- 以太网 * sl -- 串行线路IP (slip) * wl -- wlan * ww -- wwan * * 名字类型: * b<number> -- BCMA总线和新书 * ccw<name> -- CCW总线组名 * o<index> -- 车载设备的索引号 * s<slot>[f<function>][d<dev_port>] -- 热插拔插槽索引号 * x<MAC> -- MAC 地址 * [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>] * -- PCI 位置 * [P<domain>]p<bus>s<slot>[f<function>][u<port>][..]1[i<interface>] * -- USB端口号链
新的命名方案的一个小的缺点是接口名称相比传统名称有点难以阅读。例如，你可能会发现像enp0s3名字。再者，你再也无法来控制接口名了。
如果由于某种原因，你喜欢旧的方式，并希望能够选择任意名称分配给CentOS/ RHEL7的设备，你需要重写默认的可预测的命名规则，定义基于MAC地址udev规则。
下面是如何在CentOS或RHEL7命名网络接口。
首先，让我们来禁用该可预测命名规则。对于这一点，你可以在启动时传递“net.ifnames=0”的内核参数。这是通过编辑/etc/default/grub并加入“net.ifnames=0”到GRUBCMDLINELINUX变量来实现的。
然后运行这条命令来重新生成GRUB配置并更新内核参数。
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg 
接下来，编辑（或创建）一个udev的网络命名规则文件（/etc/udev/rules.d/70-persistent-net.rules），并添加下面一行。更换成你自己的MAC地址（08:00:27:a9:7a:e1）和接口（sushi）。
$ sudo vi /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:a9:7a:e1", ATTR{type}=="1", KERNEL=="eth*", NAME="sushi"
最后，重启电脑并验证新的接口名。
请注意，配置重命名后的接口仍然是你的责任。如果网络配置（例如，IPv4设置，防火墙规则）是基于旧名称（变更前）的，则需要更新的网络配置以反映更改的名称。
|
命令行基础工具的更佳替代品
命令行听起来有时候会很吓人，特别是在刚刚接触的时候，你甚至可能做过有关命令行的噩梦。然而渐渐地，我们都会意识到命令行实际上并不是那么吓人，反而是非常有用。实际上，没有命令行正是每次我使用 Windows 时让我感到崩溃的地方。这种感觉上的变化是因为命令行工具实际上是很智能的。 你在任何一个 Linux 终端上所使用的基本工具功能都是很强大的， 但还远说不上是足够强大。 如果你想使你的命令行生涯更加愉悦， 这里有几个程序你可以下载下来替换原来的默认程序， 它还可以给你提供比原始程序更多的功能。
dfc
作为一个 LVM 使用者, 我非常喜欢随时查看我的硬盘存储器的使用情况. 我也从来没法真正理解为什么在 Windows 上我们非得打开资源管理器来查看电脑的基本信息。在 Linux 上， 我们可以使用如下命令：
- $ df -h
该命令可显示电脑上每一分卷的大小、 已使用空间、 可用空间、 已使用空间百分比和挂载点。 注意， 我们必须使用 "-h" 选项使得所有数据以可读形式显示(使用 GiB 而不是 KiB)。 但你可以使用 dfc 来完全替代 df， 它不需要任何额外的选项就可以得到 df 命令所显示的内容， 并且会为每个设备绘制彩色的使用情况图, 因此可读性会更强。
另外， 你可以使用 "-q" 选项将各分卷排序， 使用 "-u" 选项指定你希望使用的单位， 甚至可以使用 "-e" 选项来获得 csv 或者 html 格式的输出.
dog
Dog 比 cat 好， 至少这个程序自己是这么宣称的。 你应该相信它一次。 所有 cat 命令能做的事， dog 都做的更好。 除了仅仅能在控制台上显示一些文本流之外， dog 还可以对其进行过滤。 例如， 你可以使用如下语法来获得网页上的所有图片：
- $ dog --images [URL]
或者是所有链接：
- dog --links [URL]
另外， dog 命令还可以处理一些其他的小任务， 比如全部转换为大写或小写， 使用不同的编码， 显示行号和处理十六进制文件。 总之, dog 是 cat 的必备替代品。
advcp
一个 Linux 中最基本的命令就是复制命令： cp。 它几乎和 cd 命令地位相同。 然而， 它的输出非常少。 你可以使用 verbose 模式来实时查看正在被复制的文件， 但如果一个文件非常大的话， 你看着屏幕等待却完全不知道后台在干什么。 一个简单的解决方法是加上一个进度条： 这正是 advcp (advanced cp 的缩写) 所做的！ advcp 是 GNU coreutils 的一个 补丁版本， 它提供了 acp 和 amv 命令， 即"高级"的 cp 和 mv 命令. 使用语法如下：
- $ acp -g [file] [copy]
它把文件复制到另一个位置， 并显示一个进度条。
我还建议在 .bashrc 或 .zshrc 中设置如下命令别名：
- alias cp="acp -g"
- alias mv="amv -g"
The Silver Searcher
the silver searcher 这个名字听起来很不寻常（银搜索...）， 它是一款设计用来替代 grep 和 ack 的工具。 The silver searcher 在文件中搜索你想要的部分， 它比 ack 要快， 而且能够忽略一些文件而不像 grep 那样。（译者注： 原文的意思貌似是 grep 无法忽略一些文件， 但 grep 有类似选项） the silver searcher 还有一些其他的功能，比如彩色输出， 跟随软连接， 使用正则表达式， 甚至是忽略某些模式。
作者在开发者主页上提供了一些搜索速度的统计数字， 如果它们的确是真的的话， 那是非常可观的。 另外， 你可以把它整合到 Vim 中， 用一个简洁的命令来调用它。 如果要用两个词来概括它， 那就是： 智能、快速。
plowshare
所有命令行的粉丝都喜欢使用 wget 或其他对应的替代品来从互联网上下载东西。 但如果你使用许多文件分享网站， 像 mediafire 或者 rapidshare。 你一定很乐意了解一款专门为这些网站设计的对应的程序， 叫做 plowshare。 安装成功之后， 你可以使用如下命令来下载文件：
- $ plowdown [URL]
或者是上传文件:
- $ plowup [website name] [file]
前提是如果你有那个文件分享网招的账号的话。
最后， 你可以获取分享文件夹中的一系列文件的链接：
- $ plowlist [URL]
或者是文件名、 大小、 哈希值等等：
- $ plowprobe [URL]
对于那些熟悉这些服务的人来说， plowshare 还是缓慢而令人难以忍受的 jDownloader 的一个很好的替代品。
htop
如果你经常使用 top 命令， 很有可能你会喜欢 htop 命令。 top 和 htop 命令都能对正在运行的进程提供了实时查看功能， 但 htop 还拥有一系列 top 命令所没有的人性化功能。 比如， 在 htop 中， 你可以水平或垂直滚动进程列表来查看每个进程的完整命令名， 还可以使用鼠标点击和方向键来进行一些基本的进程操作(比如 kill、 (re)nice 等)，而不用输入进程标识符。
mtr
系统管理员的一个基本的网络诊断工具traceroute可以用于显示从本地网络到目标网络的网络第三层协议的路由。mtr（即“My Traceroute”的缩写）继承了强大的traceroute功能，并集成了 ping 的功能。当发现了一个完整的路由时，mtr会显示所有的中继节点的 ping 延迟的统计数据，对网络延迟的定位非常有用。虽然也有其它的 traceroute的变体（如：tcptraceroute 或 traceroute-nanog），但是我相信 mtr 是traceroute 工具里面最实用的一个增强工具。
总的来说， 这些十分有效的基本命令行的替代工具就像那些有用的小珍珠一样， 它们并不是那么容易被发现， 但当一旦你找到一个， 你就会惊讶你是如何忍受这么长没有它的时间！ 如果你还知道其他的与上面描述相符的工具， 请在评论中分享给我们。
订阅：
博文 (Atom)