headless

Hadoop与Kubernetes就好像江湖里的两大绝世高手，一个是成名已久的长者，至今仍然名声远扬，一个则是初出茅庐的青涩少年，骨骼惊奇，不走寻常路，一出手便惊诧了整个武林。Hadoop与Kubernetes之间有很深的渊源，因为都出自IT豪门——Google，只不过，后者是亲儿子，正因为有大佬背书，所以Kubernetes一出山，江湖各路门派便都蜂拥而至，拥护称王。 不知道是因为Hadoop是干儿子的缘故还是因为“廉颇老矣”，总之，Hadoop朋友圈的后辈们如Spark、Storm等早都有了在Kubernetes上部署运行的各种资料和案例，但Hadoop却一直游离于Kubernetes体系之外，本文我们给出Hadoop在Kubernetes上的实践案例，以弥补这种缺憾。 Hadoop容器化的资料不少，但Hadoop部署在Kubernetes上的资料几乎没有，这主要是以下几个原因导致的： 第一， Hadoop集群重度依赖DNS机制，一些组件还使用了反向域名解析，以确定集群中的节点身份，这对Hadoop在Kubernetes上的建模和运行带来极大挑战，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解决这一难题。 第二， Hadoop新的Map-Reduce计算框架Yarn的模型出现的比较晚，它的集群机制要比HDFS复杂，资料也相对较少

前言 首先介绍下在本文出现的几个比较重要的概念： 函数计算（Function Compute） : 函数计算是一个事件驱动的服务，通过函数计算，用户无需管理服务器等运行情况，只需编写代码并上传。函数计算准备计算资源，并以弹性伸缩的方式运行用户代码，而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息 参考 。 Fun : Fun 是一个用于支持 Serverless 应用部署的工具，能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件（template.yml），协助您进行开发、构建、部署操作。Fun 的更多文档 参考 。 NAS : 阿里云文件存储NAS是一个可共享访问，弹性扩展，高可靠，高性能的分布式文件系统。在函数计算的场景中，由于其有代码包的限制，可以使用 NAS 存放一些不经常变动的文件，比如数据模型、静态资源等。 参考 。 ROS : 阿里云资源编排服务（ROS）助您简化云计算资源的管理。您可以遵循ROS定义的模板规范，在模板中定义所需云计算资源的集合及资源间依赖关系。ROS自动完成所有资源的创建和配置，实现自动化部署和运维。更多文档 参考 。 备注: 本文介绍的技巧需要 Fun 版本大于等于 3.4.0。 基本上所有的 faas 平台为了优化函数的冷启动，都会加入代码包的限制。阿里云 函数计算 （FC）也不例外。FC

接着上篇继续分析 SpringBoot 的启动过程。 SpringBoot的版本为：2.1.0 release，最新版本。 一.时序图 一样的，我们先把时序图贴上来，方便理解： 二.源码分析 回顾一下，前面我们分析到了下面这步： public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) { // 前面分析了前一部分，SpringApplication的构造方法，本文分析后一部分的run()方法 return new SpringApplication(primarySources).run(args); } SpringApplication#run方法的内容较多，准备刷屏了： public ConfigurableApplicationContext run(String... args) { // StopWatch是Spring中一个任务执行时间控制的类，记录了任务的执行时间 StopWatch stopWatch = new StopWatch(); stopWatch.start();// 开始时间 ConfigurableApplicationContext context = null; //

部署步骤: 1.tar -zxvf Apache_OpenOffice_4.1.6_Linux_x86-64_install-rpm_zh-CN.tar.gz 2.yum localinstall openoffice4.1.6-redhat-menus-4.1.6-9790.noarch.rpm 3.运行:/opt/openoffice4/program/soffice -headless -accept="socket,host=127.0.0.1,port=8100;urp;" -nofirststartwizard 4.出错:/opt/openoffice4/program/soffice.bin: error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory 5.yum install libXext.x86_64 6.no suitable windowing system found, exiting 7.yum groupinstall "X Window System" 8.nohup /opt/openoffice4/program/soffice -headless -accept="socket

大文件问题 函数计算 对上传的 zip 代码包尺寸限制为 50M。某些场景中代码包中会超过这一限制，比如未经裁剪的 serverless-chrome ，类似的还有 libreoffice ，此外常见的还有机器学习训练的模型文件。 目前解决大文件问题有三种方法 采用更高压缩比的算法，比如本文介绍的 brotli 算法 采用 OSS 运行时下载 采用 NAS 文件共享 简单的比较一下这三种方法的优劣 方法 优点 缺点 高密度压缩 发布简单，启动最快 上传代码包较慢；要写解压代码；大小受限制不超过 50 M OSS 下载解压后文件不超过 512 M 需要预先上传至 OSS；要写下载和解压代码，大概 50M/s 的下载速度 NAS 文件大小没有限制，无需压缩 需要预先上传至 NAS；VPC 环境有冷启动时延(~5s) 正常情况下如果代码包能控制在 50M 以下启动较快。而且工程上也比较简单，数据和代码放在一起，不需要额外的写脚本去同步更新 OSS 或者 NAS。 压缩算法 Brotli 是 Google 工程师开发的开源压缩算法，目前已经被新版的主流浏览器支持，作为 HTTP 传输的压缩算法。下面是在网上找到的关于 Brotli 和其他常见压缩算法对比基准测试。 从上面三幅图我们可以看出:相比于 gzip、xz 和 bz2，brotli 有最高的压缩比，接近于 gzip 的解压速度

1、Linux安装jdk 1.1、查看系统自带的jdk rpm -qa | grep jdk 1.2、删除系统自带的jdk rpm -e --nodeps java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64 rpm -e --nodeps java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.x86_64 rpm -e --nodeps java-1.7.0-openjdk-headless-1.7.0.141-2.6.10.5.el7.x86_64 rpm -e --nodeps java-1.8.0-openjdk-headless-1.8.0.131-11.b12.el7.x86_64 rpm -e --nodeps copy-jdk-configs-2.2-3.el7.noarch 1.3、安装jdk #将安装包传输到opt目录下，解压 tar -zxvf jdk-8u152-linux-x64.tar.gz\ 1.4、配置环境变量 vim /etc/prifile #配置参数 JAVA_HOME=/opt/jdk1.8.0_152 PATH=$PATH:$JAVA_HOME/bin CLASSPATH=$JAVA_HOME/lib export JAVA_HOME PATH CLASSPATH 1.5

作者 | 酒祝 阿里巴巴技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 22 讲。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载从零入门 K8s 系列文章 PPT。 导读 ：有状态应用的部署交付向来都是应用运维领域的难点之一，常见的有状态需求如在磁盘持久化状态、每个机器需要独立且稳定的网络标识、发布顺序确定性等。针对这类问题 Kubernetes 提供了 StatefulSet 控制器，作为帮助有状态应用部署和在 K8s 环境落地的 Workload。 一、“有状态”需求 我们之前讲到过 Deployment 作为一个应用编排管理工具，它为我们提供了哪些功能？ 如下图所示： 首先它支持定义一组 Pod 的期望数量，Controller 会为我们维持 Pod 的数量在期望的版本以及期望的数量； 第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照我们给出的策略来更新 Pod，同时在更新的过程中，也会保证不可用 Pod 数量在我们定义的范围内； 第三，如果我们在发布的过程中遇到问题，Deployment 也支持一键来回滚。 可以简单地说，**Deployment 认为：它管理的所有相同版本的 Pod 都是一模一样的副本。**也就是说，在 Deployment Controller 看来，所有相同版本的 Pod

第一步 检查 JDK 查看JDK版本，在命令行输入：java -version [root@test ~]# java -version bash: java: command not found 如上，证明你的linux非常干净，请直接进入 第二步 或者出现下面这种结果 [root@test ~]# java -version openjdk version "1.8.0_102" OpenJDK Runtime Environment (build 1.8.0_102-b14) OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode) Linux一般自带OpenJDK，如果明确知晓OpenJDK就是你所需要的，那么恭喜。您可以直接关掉本文啦~如果您不确定，请百度 Oracle JDK 和 OpenJDK的区别 嫌麻烦的，请直接跟着大炮老哥安装Oracle JDK(又名Sun JDK，后Sun公司被Oracle收购)，也就是我们通常意义上讲的最常用的JDK 移除OpenJDK，在命令行输入：rpm -qa|grep java [root@test ~]# rpm -qa|grep java tzdata-java-2016g-2.el7.noarch java-1.7.0-openjdk-headless-1.7.0.111