首页 文章 精选 留言 我的

精选列表

搜索[影响力排行]，共5158篇文章
优秀的个人博客,低调大师

2016 最佳 Linux 发行版排行榜【转】

转自：http://www.linuxstory.org/the-best-linux-distros-of-2016/?utm_source=tuicool&utm_medium=referral 2015年，不管在企业市场还是个人消费市场都是Linux非常重要的一年。作为一个自2005年起就开始使用Linux的Linuxer ，我门见证了Linux在过去十年的成长。2016Linux将更加精彩，所以我们选择了一些大放异彩的发行版。现在Linux Story小编就带你去领略一下各领域的风采吧！ 最好的回归发行版：openSUSE openSUSE 背后的 SUSE 公司是最老的 Linux 企业，它成立于Linus Torvalds 宣布放出 Linux 的一年后。它其实早于 Red Hat 的诞生，它也是社区主导的发行版 openSUSE 的赞助商。 在2015，openSUSE 团队决定靠拢 SUSE Linux 企业版（SLE）以便用户可以共享企业服务版本的 DNA ，就像 CentOS 和Ubuntu一样。之后，openSUSE 变成了openSUSE Leap，直接基于SLESP1 。这两个发行版将共享代码库以互惠互利，SUSE 将吸取 openSUSE 的优秀内容，反之亦然。通过这一举措，openSUSE 也抛弃了常规的发行周期，一个新的版本将和 SLE 保持一致。这意味着每个版本将有更长的生命周期。这一举措的结果是 openSUSE 将变成一个非常重要的发行版，因为潜在的 SLE 用户可以使用openSUSE Leap。然而，这还不是全部，openSUSE 同时发布了一个纯粹的滚动发行版—— Tumbleweed 。可以参考Linux Story闻其详撰写的这篇文章《生命、宇宙以及Linux 系统的终极答案？ openSUSE Leap 42.1 华丽发布》，所以现在用户可以使用超稳定的 openSUSE Leap 和 始终保持最新的openSUSE Tumbleweed。 在我记忆中没有其他发行版做了如此深刻的回归。 最可定制的发行版：Arch Linux Arch Linux是现阶段最好的滚动发行版，好吧，我可能因为我是 Arch Linux 用户而产生了偏见。更重要的是 Arch 在其他方面也表现良好，这也是为什么我选择它作为我的操作系统的原因。 Arch Linux 是一个为那些想了解 Linux 一切的人准备的发行版，因为你必须手动安装一切，它会让你学会基于 Linux 的操作系统的每个部分。 Arch Linux 是最可定制的发行版，你获得的只是一个基础系统，然后你可以在它上面建立属于你个人的发行版。不论好坏，它都不像 openSUSE 和Ubuntu，它没有额外的补丁和整合内容，你甚至可以获得上游开发者创建的内容。 Arch Linux 也是最好的滚动发行版之一。他总是更新，用户始终使用最新的软件包，并且他们还可以通过稳定的存储库运行预发布软件。 Arch 也因优异的文档闻名。 Arch Wiki 可以让我得到任何 Linux 相关的资料。 Arch 中我最喜欢的内容是它提供的所有的包和软件都可在“任何” Linux 发行版上运行。感谢Arch User Repository（AUR）。 最好看的发行版：elementary OS 不同的 Linux 发行版有不同的侧重点，在大多数情况下这都是技术差异。在很多 Linux 发行版中外观和感觉是无足轻重的——更像是一个边缘项目。不管什么角度，Linux Story一直觉得它是一个非常漂亮的系统。 elementary OS正试图改变这一切。在它里面，设计走在了前列，其原因是很明显的。该发行版漂亮的图标是 Linux 世界闻名的设计师们设计开发的。elementary OS 非常严格要求整体的外观和感觉。开发者已经创建了包括桌面环境在内的自己的组件，此外，他们只选择那些符合自己设计模式的应用程序。可以在该系统上看到 Mac OS X 的影子。 最佳新人：Solus Solus操作系统最近已经获得了相当多的关注，它是一个从头开始创建的前瞻性操作系统。它并不是 Debian 或Ubuntu的衍生物。它搭配了为集成 GNOME 从头开始构建的 Budgie 桌面环境。Solus有和 GoogleChrome OS相同的极简主义方法。Linux Story完全认同 Solus为最佳新人。 我没有使用太多 Solus，但它看起来很有希望。 Solus 不是一个“新的”操作系统，它曾经以不同的形式和名称存在。但是整个项目的新名称是在2015年才提出的。 最好的教育操作系统：ezgo Linux ezgo是一套开源、公益、免费、面向教育的电脑操作系统，基于Linux 而开发，它包含有丰富的互动教学软件和开放教材、知识，涵盖了物理、化学、地理、天文、 生物、数学、计算机等学科，矢志帮助学校的学生和教师的教育信息化，帮助孩子们和家长、老师以最方便最有效的方式接触、获取全世界最先进的知识和智慧，这是一个发源于台湾的开源项目，目前在国内是重庆Linux用户组 ChongqingLUG 在维护、开发和推广。搜集了包括 PhET在内的大量开源教材，Linux Story有幸也曾经报道过跟ezgo有关的消息，它的官方网站是http://ezgolinux.org/。关心教育的家长、学生和老师值得关注。 最好的云操作系统：Chrome OS Chrome OS不是一个典型的基于 Linux 的发行版，因为它是一个为在线活动设计的基于浏览器的操作系统。而且，由于它基于 Linux 同时它的源码是供所有人编译，所以它也很有吸引力。我每天都使用 Chrome OS ，这是一个对纯粹为网络活动而设计的极好的，免维护的，不断更新的操作系统。Chrome OS 和 Android 一起值得所有的新人来实现 PC 和其他平台的 Linux 普及。Linux Story曾经也试用过 Acer Chromebook 11，感觉相当不错。 最好的笔记本操作系统：Ubuntu MATE 大多数笔记本没有非常高端的硬件，如果你正在运行一个非常消耗资源的桌面环境的话你将不会有太多的系统资源或电池续航来供你使用，因为系统已经占用了很多。这就是我发现为什么Ubuntu MATE是一个优秀的操作系统。因为它是轻量级的，但也有应有尽有的内容给你提供不错的体验。正是由于它轻量级的设计，大部分的系统资源可供你去完成繁重的工作。我认为它在低端硬件上是一个真正优秀的发行版。 最好的旧硬件支持系统：Lubuntu 如果你有闲置的旧笔记本或者台式机，可以使用Lubuntu来令它焕发生机。Lubuntu使用 LXDE 桌面环境，但该项目已经和 Razor Qt 合并为 LXQt 项目了。尽管最新的15.04版本仍然使用 LXDE ,但是以后的版本将使用 LXQt 。Lubuntu 确实是一款适合旧硬件的操作系统。 最好的物联网操作系统：Snappy Ubuntu Core Snappy Ubuntu Core是最好的物联网以及其他类似设备的基于 Linux 的操作系统。该操作系统有很大的潜力将近乎的所有东西都变成智能设备，比如路由器、咖啡机、无人驾驶飞机等等。优秀的软件管理和为增强安全性设计的容器化将它变得更加好玩。 最好的台式机操作系统：Linux Mint Cinnamon Linux Mint Cinnamon是最好的台式机操作系统，它对硬件强大的笔记本也是最好的。我将它当成 Linux 世界的 Mac OS X 。老实说，我曾经因为 Cinnamon的不稳定而十分不愉快。但是，只要开发者选择 LTS 版本，它就变得难以置信的稳定。因为开发者不必花太多时间去跟上Ubuntu，所以他们可以花更多时间去让 Cinnamon 更好。 最好的游戏系统：Steam OS 游戏一直是桌面版Linux 的弱点，许多用户启动双系统的Windows只是为了玩游戏。Valve Software 正在努力改变这一现状。Valve 是一个提供使游戏在不同平台上运行的客户端的游戏分销商。而且，为了创建基于 Linux 的游戏框架，Valve 已经创建了他们自己的开放式操作系统——Steam OS。在2015年底，合作伙伴开始将 Steam 机器推向市场。 最好的隐私保护操作系统：Tails 当下大量的监视和营销者的跟踪（匿名跟踪的目标内容是可接受的）让隐私保护已经成为一个主要的问题。如果你的业务需要避免政府和营销机构的追踪，你就需要考虑一款从底层设计隐私保护的操作系统。 而且，在这一方面没有其他的能打败Tails。它是基于 Debian 的设计用来实现隐私保护和匿名化的操作系统。Tails非常棒，据报道，美国国家安全局（NSA）认为它是自己使命的重要威胁。 最好的多媒体制作系统：Ubuntu Studio 多媒体制作是基于 Linux 的操作系统的主要缺点之一，所有专业级的程序在Windows和 Mac OS X 上都可找到。Linux 上却没有像样的音频/视频制作软件，但一个多媒体制作系统需要的不仅仅是像样的应用程序。它应该使用轻量级的桌面环境使宝贵的系统资源如 CPU、RAM 被系统尽量少的使用，以便用于多媒体制作程序。因此，最好的 Linux 多媒体制作系统是Ubuntu Studio，它使用 Xfce 桌面环境并配备了众多的音频，视频和图像编辑应用程序。Linux Story网站很长时间也用过它来制作一些影音多媒体素材。 最好的企业级系统：SLE/RHEL 企业用户不会四处寻找运行在自己服务器上的发行版。他们已经知道选择范围：Red Hat Enterprise Linux 或者 SUSE Linux Enterprise 。这两个名字已经成为企业级系统的代名词。这些公司也在设法在容器化和软件定义上的创新来推倒当前的壁垒。Linux Story认为 RHEL确实稳定，确实好用。 最好的服务器操作系统：Debian/CentOS 如果你正打算运行一个服务器，但是又不想为RHEL 或 SLE 的维护付费，那么 Debian 或 CentOS 是你最好的选择。这些发行版是社区主导的服务器版本，它们有着黄金标准。而且，它们的支持周期很长，所以你不必担心经常升级系统。 最好的移动操作系统：Plasma Mobile 尽管基于 Linux 的操作系统—— Android 正在主宰移动领域，包括我在内的很多开源社区的成员仍然希望有一个发行版能够在移动设备上提供传统的 Linux 桌面应用程序。同时，它最好是由一个社区负责运营维护而不是一个公司以便让用户仍然是受关注的焦点，而不是以公司的财务目标为焦点。而这正是 KDE 的Plasma Mobile带来的希望。 该版本是基于 Kubuntu 的，发布于2015年。因为 KDE 社区在公众环境中遵守标准和发展东西是众所周知的，所以我对 Plasma Mobile 的未来充满希望。 最好的 ARM 设备发行版：Arch Linux ARM 随着 Android 的成功，我们已经被 ARM 设备所包围——从树莓派到 Chromebook 再到 Nvidia Shield。为 Intel/AMD 处理器编写的传统发行版将不能在这些设备上运行。虽然一些发行版专为 ARM 设计，但是大多数都只针对具体的硬件，比如为树莓派设计的 Raspbian 。这也是为什么Arch Linux ARM（ALARM）让人眼前一亮。因为它是一个纯粹由社区主导的基于 Arch Linux 的发行版，你可以在树莓派、Chromebook、Android 设备、Nvidia Shield 等上面运行它。这个发行版更有趣的是，因为 Arch User Repository（AUR）的原因，所以你可以安装许多你可能在其他发行版上无法获得的应用程序。 总结 当我完成这篇文章的时候我很惊讶和惊奇，非常令人兴奋的看到有适合每个人的 Linux 世界。如果这一年桌面版的 Linux 一直跳票也没关系，我们因 Linux 时刻高兴着！ 各位看官还过瘾吗？Linux Story 小编将一如既往为大家带来精品，敬请期待哦！ 原文链接：http://www.linux.com/news/software/applications/878620-the-best-linux-distros-of-2016LinuxStory翻译为中文，对原文有删节、补充 本文链接：http://www.linuxstory.org/the-best-linux-distros-of-2016/转载请注明，否则将追究相关责任 【作者】 张昺华 【出处】 http://www.cnblogs.com/sky-heaven/ 【博客园】 http://www.cnblogs.com/sky-heaven/ 【新浪博客】 http://blog.sina.com.cn/u/2049150530 【知乎】 http://www.zhihu.com/people/zhang-bing-hua 【我的作品---旋转倒立摆】 http://v.youku.com/v_show/id_XODM5NDAzNjQw.html?spm=a2hzp.8253869.0.0&from=y1.7-2 【我的作品---自平衡自动循迹车】 http://v.youku.com/v_show/id_XODM5MzYyNTIw.html?spm=a2hzp.8253869.0.0&from=y1.7-2 【新浪微博】 张昺华--sky 【twitter】 @sky2030_ 【facebook】 张昺华 zhangbinghua 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利.
2016-01-17
优秀的个人博客,低调大师

国内最具影响力科技创投媒体36Kr的容器化之路

本文由1月19日晚36Kr运维开发工程师田翰明在Rancher技术交流群的技术分享整理而成。微信搜索rancher2，添加Rancher小助手为好友，加入技术群，实时参加下一次分享~ 田翰明，36Kr 运维开发工程师，在 36Kr 主要负责运维自动化，CI/CD 的建设，以及应用容器化的推动。 背景 36Kr是一家创立于2010年，专注于科技创投领域的媒体公司，业务场景并不复杂，前端主要使用NodeJS进行Render，移动端有Android也有iOS，后端服务几乎全都由PHP来支持。使用PHP的主要原因是在最初进行技术选型的时候发现，PHP进行Web开发效率比较高，后来就一直这样延续下来了。 但是在后期，随着业务的突飞猛涨，在程序设计中又没能进行解耦，就导致了许多服务耦合成了一个很臃肿的单体应用，逻辑耦合严重，进而导致了很多的性能问题，随着问题越来越难改，开发任务又越来越紧，就不得不往后拖，越往后拖留下的问题就更难改，形成了一个恶性循环，留下了很多的技术债，很不利于后续的开发任务，并且一旦出现了问题，也很难追溯具体原因，所以在那时候经常听到一句话 “这是历史遗留问题” 。 B/S、C/S、单体应用，这是一种很传统 也很简单的架构，但是缺点也暴露无遗，所以经常因为一个业务逻辑的性能问题，进而影响到所有的业务。在运维侧，运维只能够通过堆机器，升配置等策略来应对，投入了很多的机器成本和人力成本，但是收效甚微，很是被动。 这种情况已经是迫在眉睫了，终于技术团队决定使用 Java 语言进行重构，将单体应用进行微服务化拆解，彻底改变这种因为单体应用故障而导致生产环境出现大范围的故障。 需求分析 + 选型 在重构计划开始一段时间后，为了节省虚机资源，我们一台虚机上运行了多个 Java 程序，但是因为没有资源隔离和灵活的调度系统，其实也会导致一些资源的浪费。并且在高并发场景下，偶尔会有资源抢占导致一个应用影响另一个应用的情况。为此，我们运维专门开发了一套自动化部署系统，系统内包括部署、监控检测、部署失败回滚、重启等基础功能。 随着当时 K8s 的风靡，还有 Rancher 2.x 的发布，我们逐渐发现，我们所面临的这些问题，它们基本都能解决，比如资源隔离、deployment 的控制器模型、灵活的调度系统，这些都有，这就是最好的自动化部署系统啊，于是我们运维侧，也开始决定向容器化进军。 在选型上，因为我们的服务基本都在阿里云上面，所以第一个想到的是阿里云。时因为我们和华为有一些业务的往来，所以华为的 CCE 也作为了备选，但是考虑到我们的服务资源全部在阿里云上，这个迁移成本实在太大了，所以就没再考虑华为云。 我们一开始使用过Rancher 1.6，但是只是用来管理主机上部署的原生 Docker。也因此对Rancher的产品产生了很大的好感。 需求方面，因为要降低我们研发人员的学习成本，容器管理平台的易用性十分重要。此外，K8s 的基础功能是必须的，因为 K8s 还在高速发展阶段，所以能需要够随时跟上更新，有安全漏洞后也需要第一时间进行更新打补丁，同时还要有基本的权限控制。而且我们公司内部没有专门的K8S团队，运维人员也只有2位，所以如果能够有专业人员进行技术上的交流，发生了问题可以有专业的服务团队来协助也十分重要。 综上，基本上就是 Rancher 完胜，UI 做得非常友好，开发人员能够很快上手，更新迭代速度也非常快，发现漏洞后也会有详细的补丁方案，认证策略也完美支持我们的 OpenLDAP 协议，能够对开发、测试、运维人员进行不同权限控制，并且也是第一家做到支持多云环境的，方便以后我们做跨云的方案。 我们这次容器化的过程，主要经历了以下几个因素的考虑，今天我就来和大家分享我们在 Rancher 上的一些实践，希望能给大家带来帮助： 应用的容器化改造 Rancher 的高可用性 容器的运维 多租户隔离 应用的容器化改造 因为我们的开发人员，有相当一部分是没有接触过容器的，为了能对开发人员更友好一些，我们的镜像分成了两层，主要的 Dockerfile 编写是由我们运维人员来编写的，而开发人员代码仓库里的 Dockerfile 是最简单的，基本上只有代码拷贝的过程和一些必传的变量，具体可以参考以下示例： ## 这是运维人员维护的 Dockerfile 示例 ## 本示例仅做参考 FROM alpine:3.8 MAINTAINER yunwei <yunwei@36kr.com> WORKDIR /www RUN mv /etc/apk/repositories /etc/apk/repositories.bak \ && echo "http://mirrors.aliyun.com/alpine/v3.8/main/" >> /etc/apk/repositories \ && apk update && apk upgrade RUN apk --no-cache add ca-certificates wget && \ wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub && \ wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.29-r0/glibc-2.29-r0.apk && \ apk add glibc-2.29-r0.apk && rm -f glibc-2.29-r0.apk RUN apk add -U --no-cache \ bash \ sudo \ tzdata \ drill \ iputils \ curl \ busybox-extras \ && rm -rf /var/cache/apk/* \ && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime COPY java-jar/jdk1.8.0_131 /usr/local/jdk1.8.0_131 ENV TZ="Asia/Shanghai" ENV JAVA_HOME=/usr/local/jdk1.8.0_131 ENV CLASSPATH=$JAVA_HOME/bin ENV PATH=.:$JAVA_HOME/bin:$PATH ENV JAVA_OPTS="-server -Xms1024m -Xmx1024m" CMD java -jar $JAVA_OPTS -Dserver.port=8080 server.jar ======================================= ## 这是开发人员维护的 Dockerfile 的示例 FROM harbor.36kr.com/java:v1.1.1 MAINTAINER developer <developer@36kr.com> ADD web.jar ./server.jar 可以看到，开发人员所维护的 Dockerfile 可以说相当简单了，这大大的降低了开发人员维护的难度。 另外，因为构建产物的大小，很大程度上决定了部署时间的长短，所以我们使用了号称最小的镜像——alpine，alpine 有很多的优点： 体积小 有包管理器、有丰富的依赖 大厂的支持，包含 Docker 公司在内的多家大厂官方使用 但是他有一个缺点，alpine 上并没有 glibc 库，他所使用的是一个 musl libc 的小体积替代版，但是 Java 是必须依赖的 glibc 的，不过早就有大神了解了这点，在 GitHub 上已经提供了预编译的 glibc 库，名字为alpine-pkg-glibc，装上这个库就可以完美支持 Java，同时还能够保持体积很小。 Rancher 的高可用性 安装 Rancher 的方式有两种：单节点安装和高可用集群安装。一般单节点安装仅适用于测试或者 demo 环境，所以要正式投入使用的话，还是推荐高可用集群的安装方式。 我们一开始测试环境就使用了单节点安装的方式，后来因为 Rancher Server 那台机器出现过一次重启，就导致了测试环境故障，虽然备份了，但是还是丢失了少量数据，最后我们测试环境也采用了 HA 高可用部署，整个架构如下图所示。 Rancher Server 我是采用的 RKE 安装，并且为了防止阿里云出现区域性的故障，我们将 Rancher Server 的三台机器，部署在了两个可用区，Rancher Server-001、003 在北京的 H 区、Rancher Server-002 在北京的 G 区。 负载均衡，我们采用的是阿里云的 SLB，也是采购的主备型实例，防止单点故障，因为 Rancher 必须使用 SSL 证书，我们也有自己的域名证书，为了方便在 SLB 上进行 SSL 证书的维护，我们使用的是 7 层协议，在 SLB 上做的 SSL 终止，Rancher Server 的架构图可以参考下图： 下游集群，也就是用来承载业务的 K8s 集群，我们也是一半一半，在阿里云的两个可用区进行部署的，需要注意的是，为了保证两个区的网络时延 <= 15 ms，这就完成了一个高可用的灾备架构。 备份方面，我们也使用了阿里云 ECS 快照 + ETCD S3 协议备份到了阿里云的 OSS 对象存储两种方案，确保出现故障后，能够及时恢复服务。 部署的详细教程可以参考 Rancher 官方文档。 容器的运维 容器的运维，这里主要指容器的日志收集和容器监控，容器监控方面呢，Rancher 自带了 Prometheus 和 Grafana，而且和 Rancher 的 UI 有一些整合，就非常的方便，所以监控方面我就不展开讲了，我主要说一说日志收集。 在 K8s 里，日志的收集相比传统的物理机、虚机等方式要复杂一些，因为 K8s 所提供的是动态的环境，像绑定 hostpath 这种方式是不适用的，我们可以通过以下这个表格直观的对比一下： 可以看到，K8s 需要采集的日志种类比较多，而容器化的部署方式，在单机器内的应用数是很高的，而且都是动态的，所以传统的采集方式是不适用于 K8s 的。 目前 K8s 的采集方式大体可以分为两种，被动采集和主动推送。 主动推送一般有 DockerEngine 和 业务直写两种方式：DockerEngine 是 Docker 的 LogDriver 原生自带的，一般只能收集 STDOUT、一般不建议使用；而业务直写，则需要在应用里集成日志收集的 SDK，通过 SDK 直接发送到收集端，日志不需要落盘，也不需要部署Agent，但是业务会和 SDK 强绑定，灵活性偏低，建议对于日志量较大，或者对日志有定制化要求的场景使用。 被动推送是采用部署日志收集 Agent 进行采集的，有两种方式，一种是 Daemonset 每个机器节点上部署一个 Agent，还有一种 Sidecar，每个 Pod 以 Sidecar 的形式部署一个 Agent。 Sidecar 部署方式比较消耗资源，相当于每个 Pod 都有一个 agent，但是这种方式 灵活性以及隔离性较强，适合大型的 K8s 集群或者作为 PaaS 平台为业务方提供服务的群使用，Daemonset 部署方式，资源消耗较小，适合功能单一、业务不多的集群。 结合我们自身的场景，属于小规模集群，并且业务也不算多，我们选择了 Daemonset 的部署方式，在测试环境，我们经过调研选择了阿里开源的一个日志收集组件log-pilot GitHub 地址是：github.com/AliyunContainerService/log-pilot ，通过结合 Elasticsearch、Kibana 等算是一个不错的 K8s 日志解决方案。 因为我们的服务器都在阿里云上，我们运维人员比较少只有2位，没有精力再去维护一个大型的分布式存储集群，所以我们的业务日志选择存储在了阿里云的日志服务，所以在生产环境，我们的 K8s 也使用了阿里云日志服务，目前单日日志 6亿+ 没有任何问题。 使用阿里云收集日志呢，你需要开通阿里云的日志服务，然后安装 Logtail 日志组件 alibaba-log-controller Helm，这个在官方文档里有安装脚本，我把文档链接贴在下面，在安装组件的过程中会自动创建aliyunlogconfigs CRD，部署alibaba-log-controller的Deployment，最后以 DaemonSet 模式安装 Logtail。然后你就可以在控制台，接入你想要收集的日志了。安装完以后是这样的： Logtail支持采集容器内产生的文本日志，并附加容器的相关元数据信息一起上传到日志服务。Kubernetes文件采集具备以下功能特点： 只需配置容器内的日志路径，无需关心该路径到宿主机的映射 支持通过Label指定采集的容器 支持通过Label排除特定容器 支持通过环境变量指定采集的容器 支持通过环境变量指定排除的容器 支持多行日志（例如java stack日志） 支持Docker容器数据自动打标签 支持Kubernetes容器数据自动打标签 如果你想了解更多，可以查看阿里云日志服务的官方文档： https://help.aliyun.com/document_detail/157317.html?spm=a2c4g.11186623.6.621.193c25f44oLO1V 容器的多租户隔离 我这里所讲的，主要指的是企业内部用户的多租户隔离，而不是指的 SaaS、KaaS 服务模型的多租户隔离。 在权限方面，因为我司对于权限的管控较严格，而 Rancher 恰好提供了非常方便的基于 集群、项目、命名空间等多个粒度的权限控制，并且支持我司基于 OpenLDAP 的认证协议，非常便于管理，我可以给不同项目组的开发、测试人员开通相对应的 集群/项目/命名空间的权限。 比如下图，我可以给集群添加用户、也可以给某个 Project 添加用户，并且可以指定几个不同的角色，甚至可以自定义角色。 比如场景1：我可以给 项目组长，分配开发环境集群->项目1 所有者(Owner)权限，然后项目组长可以自由控制给本项目添加他的成员，并分配相应权限。 场景2：我可以给 测试经理，分配测试集群的所有者(Owner)权限，由测试经理来分配，谁来负责哪个项目的测试部署，以及开发人员只能查看日志等。 在资源方面，一定要进行容器的资源配额设置，如果不设置资源限额，一旦某一个应用出现了性能问题，将会影响整个 node 节点上的所有应用，K8s 会将出现问题的应用调度到其他 node 上，如果你的资源不够，将会出现整个系统的瘫痪，导致雪崩。 Java 应用的资源配额限制也有一个坑，因为默认 Java 是通过 /proc/meminfo 来获取内存信息的，默认 JVM 会使用系统内存的 25% 作为 Max Heap Size，但是容器内的/proc/meminfo是宿主机只读模式挂载到容器里的，所以采取默认值是行不通的，会导致应用超过容器限制的内存配额后被OOM，而健康检查又将服务重启，造成应用不断的重启。 那是不是通过手动参数设置 JVM 内存 = 容器内存限额呢？不行！因为 JVM消耗的内存不仅仅是 Heap，因为 JVM 也是一个应用，它需要额外的空间去完成它的工作，你需要配置的限额应该是 Metaspace + Threads + heap + JVM 进程运行所需内存 + 其他数据 关于这块，因为涉及到的内容较多，就不进行展开，感兴趣的同学可以自己去搜索 一下。 总 结 因为我们的业务场景并不复杂，所以我们的容器化之路，其实走的也相对来讲蛮顺畅的，我们的运维人员很少，只有 2 位，所以我们也没有太多的时间精力去维护太多的自建系统，我们使用了很多的阿里云产品，包括 Rancher，他很方便的部署方式，友好的 UI，包括集成好的监控等等，在容器化之路上给了我们很大的信心。 我们使用构建两层镜像的方式，降低了开发人员的学习复杂度。使用了小体积镜像 alpine + 预编译 glibc 减小了镜像体积。提高了部署的时间，在架构上，我们采用了阿里云双区机房的灾备的架构，以及完备的备份方案。使用 Daemonset 部署的日志收集组件，收集到阿里云日志服务，支撑我们 6亿/日的日志系统。Rancher 还提供给了我们深度集成的监控系统、多租户隔离等。还有我们自己踩坑 踩出来的资源配额设置。 其实容器化并不复杂，如果没有 K8s，我们需要自己构建健康监测系统、发版系统、维护不同的主机环境，不能细粒度的进行资源划分，不能更有效的利用计算资源，运维的工作主要是什么？在我看来其实就是 节约成本、提高效率。虚拟化、自动化、智能化、高性能、高可用、高并发 等等，这些无一不是围绕着成本和效率这两个词，而 K8s 其实已经帮我们都做好了，而像 Rancher 这种编排平台又帮我们降低了 K8s 的学习复杂度，所以你要做的就是加入 K8s，好了，到这里这次的分享就结束了。感谢~ 社区QA Q1：K8S在生产环境的高可用存储方案有推荐吗？ A1：存储方案没有标准答案，我们主要使用阿里云，所以用的是阿里云的块存储，比较常见的方案还有 Ceph、GlusterFS、Portworx、OpenEBS 等，他们各有优劣，需结合自己的业务需求进行选择 Q2：灰度发布，Kubernetes网络流量可以通过服务网格分流实现网络层面的分发，但是涉及到应用大版本的更新时候，涉及到数据库结构的变更的时候，如何实现灰度发布？ A2：没有遇到过这个场景，不过提供一个思路，可以准备两套数据库，网络分流也可以分流到不通数据库，具体需要你自己验证一下是否可行 要分清楚这是两层，一层是逻辑层，一层是数据层，不能混为一谈 Q3：Pipeline是用什么做的？Pipeline下，如何处理同一个分支，需要并行测试多个版本的场景？我用Rancher的Pipeline，局限性比较大，就是同一个分支无法并行多套进行测试。命名空间在使用，但是同一个分支下，命名空间是写在.rancher.yml下的，所以无法区分，Rancher的Pipeline不能在外面注入变量进行区分。 A3：Rancher 的 Pipline 目前还是有一些不够灵活，我们使用的是自建 Jenkins 做 Pipeline 的，并行测试，可以用命名空间等隔离策略进行隔离，或者准备多套测试环境 Q4: 你们运维的Dockerfile和开发的Dockerfile是怎么合并的？ A4：开发的 Dockerfile 是 From 运维的 Dockerfile Q5：你们k8s的漏洞扫描用的什么工具？一般什么级别的镜像漏洞需要进行修复？ A5：暂时没有使用漏扫工具，我们主要根据 Rancher 企业服务通知的修复建议进行修复 Q6: 就是比如说从外网，通过service ip能够登陆并且管理容器。想实现这一步必须通过将service ip暴露出来，然后这个service ip怎么暴露出来？麻烦解答一下。 A6：如果需求是管理容器，其实可以使用 Rancher 的用户权限控制，让某一用户拥有某一容器的权限，暴露 service ip 到公网，让用户管理容器是无法实现的 Q6 : 好的，谢谢，我还有一点不明白，这个service ip有什么办法能让他暴露出来呢？你意思是说让不同的用户通过rancher平台去管理不同的容器吗？麻烦再给解答一下，谢谢。 A6：可以使用 NodePort 暴露，通过 Node ip 和 端口进行访问，或者使用 公有云的负载均衡产品 Q6 : 我不是这个意思，我是想把service ip暴露出来，不只单单想通过集群内部访问。 A6：service ip 本来就是 K8s 内部的，暴露不了，只能转发 Q7: 为何没有放在3个可用区，如果可用区H挂掉，是否会导致集群不可访问？ A7：3个可用区当然也是可以的，Rancher HA 架构，只要有一个 Server 可用就没有关系 Q8：请教下你们多套开发测试环境的pipeline是怎么样的流程呢 (差异化)？有使用helm template吗，方便讲解下更多细节么？ A8：目前是通过 Jenkins 部署参数，部署的时候可以选择 命名空间、环境标识、分支等，通过 sed 修改 template Q9：请问你们的devops流是怎样的呢？一个环境对应一个docker镜像，还是说test pre prd共用一个docker镜像呢？如果是一个docker镜像共用test pre prd的话是怎么做的呢(比如不同环境的配置以及开发的协‘同开发流)？ A9：我们是用的同一个镜像，部署时通过选择不同的环境标识参数，程序会自动注入不同环境的配置，需要开发进行一些相应的配置修改 Q10:不大懂容器的资源限制该如何配置，自己配置了感觉不起作用 A10：Rancher 可以在项目、命名空间、Pod 三个粒度进行设置，优先级相反
2021-01-21
优秀的个人博客,低调大师

苹果WWDC与谷歌I/O开发者大会谁更有影响力 ?

摘要： 一年一度的Google I/O和WWDC均已结束，两个开发者大会的关注重点都在系统之上，并都致力于开发统一平台。那么，从桌面和移动操作系统、智能手表、音乐、地图到数据中心基础设施等，Google和Apple究竟谁更胜一筹？ Google I/O和Apple WWDC是开发者们的两大盛宴，因为往往在会议期间两家科技巨头都会带来历年的最新产品、技术以及对未来的展望。今天我就来带大家PK一下谷歌和苹果在历年的开发者大会中，谁更能引领科技发展。 Google I/O 简史 Google I/O是由谷歌举行的开发者年会,设计的内容从最初的开放网络技术开发网络应用发展到现在的智能硬件和云端服务.Google I/O大会以前的名字为 Google Developer Day，分别在 2006 及 2007 举行, 所以我们熟悉的开发者大会沿用了下来。然后Google I/O 这名字是有含义的：I = Innovation，O = Open，另一方面，一个程式员第一件事要学的，也是电脑的 I/O : I = Input，O = Output。 Apple WWDC 简史 WWDC – Apple Worldwide Developer Conference。 相比年幼的 Google I/O，WWDC 就像是个盛年而成熟的男人。由 1996 年开始，Apple 每一年的年中都会在加州举行, 到今年的 WWDC 已经数十届了，通常在公佈开始接受报名后，只在一週之内便已完全爆满！ 自 1998 年开始的 Keynote Show，leader们的个人表演，已经是每年的 WWDC 重头戏。所有人在排队进场时，看到各大媒体的部署都特别感受到什麽叫全球焦点。 文化异同 其实如果要说的话，明显地 Google I/O 是将 WWDC 作为蓝本，向同一个目标出发：取得开发人员的心。 对于取得开发人员的欢心方面，苹果一向是其中的表表者。过去二十多年，即使 Apple 曾经进入最低潮的年代，但依然是有一班忠心而优秀的第三方开发人员，为它孜孜不倦地开发软件。由 OS-9 到 OS-X 的钜大进化，苹果能够成功，除了 OS-X 本身是基于 Unix 的优良平台外，第三方开发人员的努力实在是功不可没。而今时今日 iOS 上的 Appstore 能够带领手机软件平台，亦可以说是一大批独立开发人员，以及小型的软件开发公司的功劳。 特别要一提，苹果自家的开发功具 X-Code，亦跟 Apple 一向的产品一样，十分 User Friendly。今年即将推出的 X-Code 4.0，亦看到有很多贴心的设计，使开发人员在开发时更快方便快捷。 WWDC 以及 I/O 大会，其实主角都是有一至两场的 Keynote，然后加了一系列的技术讲座，再加上有分门别类，接近 1 对 1 的 Lab Session。试想想，平常你根本没有机会可以直接跟 Chrome 或者 Safari 的开发者面对面谈谈你开发时候面对的难题吧。特别是 Apple，除了是 WWDC 外，它们的员工一向很少会直接跟用家及开发人员接触。 难以形容的优越感 很多参加的开发者感觉最强烈的就是 Google 的人员没有 Apple 人员的那种优越感。Google 的员工，一般给人的感觉都是亲切而技术相当了得，虽然是 Hacker 高手但也不会拒人于千里之外。Google I/O 的很多方面都给开发人员一种亲切而开放的感觉，同时亦是用心地去使你进入开放的 Web 开发世界。 Apple 的就不同了。整个 WWDC 给你的感觉都是：你能来 WWDC 你真的是幸运啊。可能你会问，到底是那裡不同，但我只能说这个是整体加在一起的感觉。由员工精心打造的 Presentation，到 Lab Session 内的讲解，以致于其他在会内的安排等等，都能感受到其中的差别。没法子啊，今时今日的 Apple，是手机界的老大哥，不再是以前要讨好开发人员的年代了。 要说明这意思，想借用在 Twitter 内，有一位 Apple 的开发人员说了一句：「Apple 是串，但它串得起！」(这句是广东话，意思是：Apple 是看不起人，但它有实力可以这样作)。大家应该明白了吧。 开放对封闭 – Web App vs Native App 其实，在 I/O 跟 WWDC 内，你可以完全切身的体会两者的分别。Google 主要是希望你为 Web 多开发厉害的 Web Application，Apple 主要是希望你再多多开发收费的 App，最好是开发游戏 (从大量的 Game 相关 Session 可以看得出来)。 由多方的讯息都看到，其实 Android 的出现可以说是 Apple 迫出来的。因为 Google 深明白 Apple 平台的封闭，相信 Google 一早便预计到了。我们还不知道未来能否再见到使用 Admob 或者 Google Adsense for Mobile 的 App 可不可以上到 Appstore 呢。 iOS 改变了 WWDC，同样地 Android 也改变了 I/O。Google 已刻意地在第二天的 Keynote 才提到 Android，但还是不能避免地成为 I/O 的主角。我相信 Google 还是想以 Web 为 I/O 的主角的。 其实我相信以 Google 的力量，要做到 Android Market 上所有 App 都能在全球售卖絶不是难事，但为什麽它花了几年时间还没有完成？大家想一想，Google 的最主要收入是什麽？虽然笔者不想这样猜，但事实告诉我们，Apple 有心以 Native App 称霸市场，结果由基本的 Payment 到 In-App Purchase 都搞得头头是道。Google 在这方面真的是使有心在 Android 平台上掘金的开发人员相当失望。 Google 之意不在酒？ 对 Google 来说，看来开放的政策本身也是一把两刃利剑。Chrome OS，本身就是希望大家主力写 Web App 来取代 Native App。初生两年的 Android，却因为 Symbian 以及 Windows Mobile 的不济，成为单挑 Apple 霸权的白骑士。Android Market 虽然本身是比 App Store 开放，但相比 Chrome OS 的 Web App，还是两码子的事吧。 Google 最后会将全部精力放在 Android App 还是 Chrome OS 的 Web App 上？不过无论 Google 取向如何，Apple 跟 Google 之争，其实也是开发者之争。 我想大家以后还是静心看看这场开发者争夺大战吧。
2018-07-03
优秀的个人博客,低调大师

世界上网速更快的国家排行榜揭晓！

电脑和互联网是最伟大的发明之一，互联网拉近了人之间的距离，也让人们能够体验更多的东西，世界上存在网速最快的国家，我们列出了互联网速度最高的十大国家，下面就一起top9世界上网速最快的国家。 世界上网速最快的国家Top9：芬兰 17.7Mbps 芬兰拥有全球最快的互联网服务之一，芬兰人以17.7Mbps的速度使用互联网。这个速度适合下载图片和音乐文件，还可以做很多其他的工作，如发送邮件，上网，访问社交网站和观看视频，也可以用这个速度上传很多文件。 世界上网速最快的国家Top8：捷克共和国 17.8Mbps 捷克不仅有利于旅游景点，而且还有良好的互联网服务，互联网的速度大约是17.8Mbps，这个速度适合下载各种文件，浏览网页，观看许多高清视频和访问社交媒体网站。 在捷克共和国的人们喜欢看电影和许多其他类型的有趣视频，捷克在全国各地都有良好的互联网服务，速度很快。 世界上网速最快的国家Top7：荷兰 17.9Mbps 荷兰在全国有一半以上的人口在家中有互联网连接，互联网在这个国家的速度是17.9 mbps。这个速度已经足够完成你在互联网上日常工作的任何活动，比如下载各种歌曲和视频，大中型文件，看高清电影和浏览网页。 世界上网速最快的国家Top6：日本 18.2Mbps 日本的光纤传输速度非常快，每个部分都能提供快速的互联网连接，日本的互联网速度平均为18.2Mbps。 这个速度非常好，许多人可以通过观看电影和各种视频同时访问互联网连接，日本的一些提供商提供大约2gbps的互联网连接。 世界上网速最快的国家Top5：拉脱维亚 18.3Mbps 拉脱维亚有很好的互联网连接速度，大约为18.3 mbps的速度使用互联网，速度非常快。这个速度对于同时下载多个电影和视频已经足够了，多数家庭都有连接互联网，并且拥有较高的网速。 世界上网速最快的国家Top4：瑞士 18.7Mbps 瑞士是世界上互联网连接速度最快的国家之一，这个国家有18.7 Mbps的互联网连接速度，这个速度适合所有在线活动，比如上传和下载图片，视频以及大电影，互联网服务每年在这里都有所改善。 世界上网速最快的国家Top3：瑞典 20.6Mbps 是瑞典平均使用20.6 mbps速度的互联网，这个速度非常适合在互联网上做任何事情。瑞典人民享受连续的互联网连接，没有任何问题。许多人可以同时执行各种在线任务。 世界上网速最快的国家Top2：挪威 21.3Mbps 挪威使用速度为21.3 mbps的互联网，网速在每年都在改善，以提供更好的互联网服务。这个速度适合上传或下载各种图片和其他大文件，挪威人可以在几分钟内下载电影。 世界上网速最快的国家Top1：韩国 29Mbps 韩国以29Mbps的速度使用互联网，大电影的下载只需要1-2分钟，几乎韩国所有家庭都有连接互联网。 补充：世界上网速最快的地方是NASA，下载速度91gbps。
2020-04-07

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册