Search Results for: man

解决 jvisualvm 启动后长时间 Computing description... 的问题

2020-08-18 | 阅读(1,462)

Java 虚拟机分析工具用 JDK 自带的 jconsole, jvisualvm, 和  jmc(Java Mission Control) 就已经非常好了，还真极少情况下(甚至没有)非得用商业的 Profiler 工具如 YourKit Java Profiler 或 JProfiler 的情况。用于实时观察 JVM 的内存, CPU, 线程等运行状况，对比 Heap 快照，发现线程死锁的应用情景，我比较喜欢用 jvisualvm(VisualVM)。

有很长一段时间，因为在家办公司，只要连接到公司的 VPN 后再执行 jvisualvm 来打开 VisualVM 时，会有很长的时间(可能长达 10 几分钟)卡在窗口右下角状态栏的 Computing description...，要等到它消失后才能开始连接 JVM，这时候我的 Java 应用可能早就退出了。要是本地不连 VPN 的话就正常，启动 VisualVM 是正常的，但调试有些工作项目又必须连接公司的 VPN。

这种使用 VisualVM 的体验有如恶梦一般，还是有经常要用到 VisualVM 的需求，所以再也不能忍受这种无谓的等待。依然是 Google + StackOverflow 的模式，找到原来罪魁祸首是 /etc/hosts 中的 127.0.0.1 这个条目。 阅读全文 >>

Python 包管理及虚拟环境的应用(四: conda)

2020-07-31 | 阅读(2,272)

一年半以前写了关于 Python 包管理及虚拟环境系列

  1. Python 包管理及虚拟环境的应用(一: pip)
  2. Python 包管理及虚拟环境的应用(二: virtualenv)
  3. Python 包管理及虚拟环境的应用(三: pipenv)

其中历数了 virtualenv, python3 -m venv, pipenv, 并提到了 pyenv 和 conda。但对 pyenv 和 conda 未作介绍，其中 conda 似乎不该错过。 Anaconda 着力于为数据分析提供支撑，并与 Jupyter Notebook 有更完美的结合，而且 PyCharm 中对它也有很好支持。因此本文来了解一下 conda 以及 Anaconda。

首先 Anaconda 是什么，它是一个用于科学计算的，跨平台的包管理与 Python 环境的工具，它方便的解决了多版本 Python 并存，切换及第三方包安装的问题。所以 Anaconda 不只是像 venv, pipenv 那样的创建管理 Python 虚拟环境，还承担了系统软件的安装管理，像 Mac 下的 brew 那样的功能。一般来说我们没有必要安装 Anaconda, 只需要安装 Miniconda 获得 conda 这个命令行工具即可。 阅读全文 >>

Flask, Vue.js 中集成 Bootstrap/BootstrapVue

2020-07-04 | 阅读(1,707)

紧接上一篇 Flask 和 Vue.js 开发及整合部署实例，来体验一下它们与 Bootstrap/BootstrapVue 的集成。漂亮的网站少不得一个好的 CSS 框架，现在有许许多的 CSS 框架可选，纯 CSS 的, 轻量级的, 含 JS 的 CSS 框架，如 Pure, Bulma, Spectre, 国产的 Element 等。而我总觉得 Bootstrap 更是五臟俱全，像 Element 专为 Vue.js 打造的一样，Bootstrap 也有 BootstrpVue 那样一个结晶品。

本文准确的内容应该是关于 Vue.js 与 Bootstrap/BootstrapVue 的话题，与 Flask 没什么事，不过这里呢，还是强拉上 Flask, 由 Flask 的 API 来产生一些数据。

同样是阅读 Flask和Vue.js构建全栈单页面web应用【通过Flask开发RESTful API】的一个实践品。本篇基于 Flask 和 Vue.js 开发及整合部署实例 中的步骤建立的项目 flask-vue-app，方便起见，用了一个新项目名称 flask-vue-bootstrap。记得我们为 Flask 和 Vue.js 分别建立了 backend  和 frontend 两个子项目。 阅读全文 >>

Flask 和 Vue.js 开发及整合部署实例

2020-07-01 | 阅读(6,130)

想做些简单的 Web 工具，首先想到的是 Flask + Vue.js, 当然可以完全用 Flask 自己的页面模板 Jinja2, 但一个网站项目不能享受到像 Vue.js, React 类似框架的灵活性真是太可惜了。于是 Flask 只专注于 API, 页面逻辑全用 Vue.js 的组合就成了我的首选，Flask 方面还能进一步选择 FlaskRESTful 框架。还需做得更漂亮的话，CSS 框架可选择 Bootstrap 或与 Vue 紧密集成的 BootstrapVue, 这是后话。

本文主要参考 Flask和Vue.js构建全栈单页面web应用【通过Flask开发RESTful API】的前部分，英文原文在这里 Developing a Single Page App with Flask and Vue.js。

开发过程中我们可以保持 Flask 和  Vue.js 为单独的两个项目，并启动各自的服务，比如 Flask 是 http://localhost:5000, Vue.js 项目通过 npm run serve 启动在 http://localhost:8080，借助于 node js 的功能，修改 Vue.js 项目的内容能够自动刷新网页。要是开发中把静态文件全放在  Flask 项目中，那么任何对静态文件的修改都必须重启 Flask  服务。虽然 Debug 模式启动的 Flask 在看到它的目录中有任何修改时也能自动重启，但对静态文件的修改重启 Flask 没这个必要性。 

但部署时需进一步整合，最终只需要启动 Flask  服务，而无须两个，方便部署。如果是以 Docker 容器的方式发布，使用 docker-compose 来编排两个容器来发布也还算不错。更专业的部署方式应该是 Vue.js 的静态内容放到专门的 Web 服务器，如  Apache/Nginx 中，Flask 也通过 wsgi 与 Web 服务器集成起来。 阅读全文 >>

Docker attach 后断开时不退出容器

2020-06-29 | 阅读(3,738)

docker attach 可以连接上 Docker 容器的标准输入，输出和错误输出。比如 docker attach 连接后就能显示容器中用 ENTRYPOINT/CMD 启动进程的输出内容内容。想要断开会话连接怎么做呢？ctrl - c, 控制台是不再显示了，可以容器也被终止了，显然这是一个危险的操作。

ctrl - c 不仅仅关闭了 docker attach 本身，因为它的默认参数 --sig-proxy 是 true，所以 SIGKILL 信号同时传递到了 ENTRYPOINT/CMD 的 PID 1 的进程，所以形成了双杀的效果。我们来试一下

如果是在生产环境下，用 docker attach 连接下控制台看下输出，然后不小心像终止 tail -f 命令一样用 ctrl - c  退出，结果服务断了。所以更为小心的操作还是用 docker logs。 docker attach 的优势只是在于能查看实时的控制台输出。 阅读全文 >>

两种最基本的排序算法: 冒泡和选择

2020-04-14 | 阅读(477)

因 COVID-19 漫延各自居家，也更有闲时，便拣起一本关于算法的书籍来研究。本不是科班出身，算法方面自然是自己的薄弱环节。平时用各种 SDK，只大概听说了些算法，仅能就自己如何选择哪种实现而作为参考。

如今阅读的是一本入门的书籍，名为 《算法图解》，英文版书名是 《Grokking Algorithms》。 该书图文并茂，十分适合初学者，关于排序最基本莫过于冒泡与选择排序。该书并未提及冒泡，而是直接从选择排序切入，在阅读本书之前我就一直对这两咱排序方式傻傻不分。一直以为头脑中的选择排序就是冒泡排序，那就来看下什么是真正的冒泡排序。 阅读全文 >>

Kubernetes 学习笔记(二) - 部署和访问应用

2020-04-09 | 阅读(374)

前边折腾了各种安装 Kubernetes 集群的操作，还跑到 AWS 上撸了一把 EKS，也在 Kubernetes 上部署过服务。继续更深一步的学习如何部署应用和怎么通过 Service 去访问 Pod 中的应用，顺带看看内部的网络是怎么流转的。

测试平台还是以本地启动的三个 Vagrant 虚拟机组成的 Kubernetes 集群，安装方法见 Kubernetes 学习笔记(一) - 初上手。

  1. k8s-master  (172.28.128.14)
  2. k8s-node1    (172.28.128.10)
  3. k8s-node2   (172.28.128.11)

测试应用的镜像为 yanbin/python-web, 代码见 github 上的 yabqiu/python-web-docker/app.py, 一个默认启动在  80 端口上的 Flask Web 应用，输出为当前 hostname  和一个唯一标识符。

部署应用

《每天5分玩转Kubernetes》里用的 Kubernetes 是 1.7 版本，其中还在用 kubectl run 的方式来部署应用(它会产生一个隐式的 deployment 对象)，该方式已在 Kubernetes 1.12 中不推荐使用了，建议用 kubectl create deployment...，而实际中更应该用 yaml 文件编排后再 kubectl apply -f <your-yaml-file>, 这样多种对象可以编写在一起，更方便日后同样的命令更新各种对象，或者用 kubectl delete -f <your-yam-file> 批量删除所创建的对象。 阅读全文 >>

AWS EKS 执行 kubectl 时 error: You must be logged in to the server (Unauthorized)

2020-04-06 | 阅读(5,630)

在 AWS 上创建好 EKS 后，想要在本地用  kubectl 来管理 EKS，必须用 aws eks update-kubeconfig 来更新本地的 ~/.kube/config 文件或者 KUBECONFIG 环境变量指向的别的配置文件。

比如说你创建 EKS 的用户在本地 ~/.aws/credentials 中的 profile 是 my-aws-profile, 那么完整的 update-kubeconfig 命令就是

$ aws eks --profile my-aws-profile --region us-east-1 update-kubeconfig --name myeks-cluster
Updated context arn:aws:eks:us-east-1:069762108088:cluster/myeks-cluster in /Users/yanbin/.kube/config

再来执行 kubectl get pods 如果出现错误 error: You must be logged in to the server (Unauthorized)，肯定是因为你使用的 awscli 命令比较老(到底有多老呢？在 github 上已经无法追溯了，大概是 1.16.266 之前的)。大约生成的 ~/.kube/config 文件末尾像下面那样 阅读全文 >>

搭建使用 AWS 的 Kubernetes EKS 服务

2020-04-05 | 阅读(2,039)

前面从无到有或是分别以 Docker Desktop, Minikube, kind 来搭建过 Kubernetes 集群。而如今各大云服务提供商基本都推出了各自的 Kubernetes 服务，例如：

  1. Google GKE - Google Kubernetes Engine
  2. Amazon EKS - Amazon Elastic Kubernetes Service
  3. Microsoft AKS - Azure Kubernetes Service
  4. IBM Cloud Kubernetes Service
  5. Alibaba Cloud Container Service

所以对 Kubernetes 的进一步学习过程中何不一跃而直上云霄，直接尝试 AWS 的 EKS 如何搭建。EKS 是在 2018 年 6 月份正式推出，见 Amazon Elastic Container Service for Kubernetes Now Generally Available。EKS 在 AWS 上是与 ECS 并列的服务，它们的功能也比较类似，都是伸缩性的容器服务，ECS 配置管理更分散，EKS 本身就是一个集群管理工具。它们也有些共同的东西，如 Auto Scaling Groups, Launch Templates。

现在用 Terraform 脚本来演示一下如何创建一个 EKS 集群，并启动三个 EC2 Worker 节点(EKS 也支持 Fargate Worker 节点)，并部署一个应用。Terraform 脚本将会列出完成该任务的基本要素，也将会看看背后发生了什么。 阅读全文 >>

Docker 容器内进程与 Namespace

2020-03-29 | 阅读(1,512)

原本是继续阅读《每天5分钟玩转Kubernetes》一书的，发现该书所用的 Kubernetes 版本着实有点老旧( 1.7), 当前版本是 1.18。操作起来有些不同，所以找来了最新的 《Kubernetes in Action》第二版 来看，该书还在写作当中。第二章全是讲 Docker 的内容，本人读书有个不好的习惯，就是不喜欢跳过跳过。看了总会有收获的，这不，就从中稍微理清了 Docker 容器内进程与 Namespace 的关系。

Docker 容器间的进程本质上是宿主主上的一个进程，它能相互隔离靠的是 chroot, namespace 和 cgroup(对 CPU, 内存，磁盘，带宽等的配额)。千万不要认为启动一个 Docker 容器就是启动了一个虚拟机。

其中 namespace 实现了以下几项资源的隔离

  1. Mount: 挂载点(文件系统)
  2. PID: 进程 ID
  3. Network: 网络设备，网络栈，端口等
  4. IPC： 进程间通信，信号量，消息队列和共享等
  5. UTS： 主机名和域名
  6. User ID: 用户和组 ID

阅读全文 >>